Best way to save files

[David Patrzeba]

Hey all,

This is my first post, so I am going to do my best to make sure everything is right before this posts, but if I miss something please let me know so I can fix it (I know you guys will).

Anyway, I was wondering how most people have their programs save their files. Do they use DB, XML, JSON, regular text file. Also what makes you decide what method to use, in other words can someone give me a few test cases for each use.

-David Patrzeba

[Jesper de Jong]

Whether you use a database or a regular file, and which format you use in case of a file, depends entirely on the application you're writing. There's no "one size fits all" answer to this question.

In web applications, data is most often stored in a database, and formats such as XML and JSON are often used for communication between the client part and server part of the web application.

If you'd write a desktop application in which the user can create and save documents, storing those documents in files in some appropriate format will probably be better than storing the documents in a database.

[David Patrzeba]

OK,

So right now I am writing a desktop application. Now I want to give my files their own extension and I want to make sure that the files can not be accessed except through the client program. If you can just point me at a library or tutorial that describes how to do this that would be great.

-dlp

[Steffen Schmitt]

But this is not necessarily a matter of file extension.

Other applications can always open some kind of stream to read in or write to your files.

To save program state Preferences may be a means of avoiding this.

Another possibility consists in the use of a Properties file which is a plain-text file thus enabling you to spot possible file corruptions easily.

But maybe there's cleverer ways to accomplish this.

Hope this helps -


Steffen

[Rob Spoor]

David Patrzeba wrote:Now I want to give my files their own extension and I want to make sure that the files can not be accessed except through the client program.

That means you can forget any text format, including properties files, XML and JSON. A database is possible but you'll need to make sure that only your program has access to this database. Perhaps HSQLDB allows this; you can then simply use a file database.

The alternative is go binary. Binary files are harder to read than text files (but not impossible if you know the format). There are again some options:
- use Java's serialization mechanism. Just create a settings class that implements Serializable.
- use a custom binary format (there are too many ways to explain them all).

[Jesper de Jong]

Rob Prime wrote:- use Java's serialization mechanism. Just create a settings class that implements Serializable.

Using Java serialization for saving documents in files is a bad idea. Serialization is really not suited for long-term storage of data. That's because there is a very tight coupling (a one-to-one mapping) between your Java classes and the content of the serialized files. This means that if you change your program, then old serialized files become unreadable.

Serialization is fine for temporary storage (for example for caching objects) or for transporting objects through a network, but don't use it for storing for example documents.

Why do you want your file format to be proprietary and unreadable for other applications? Your users will be much happier if you write your files in a standard, well-documented format, so that they can use their data in other programs if they want. If you have stuff that needs to be hidden, consider using encryption. Security by obscurity (i.e. storing data in a proprietary format) is not really secure at all (some hacker will reverse engineer the format sooner or later).

[David Patrzeba]

Thanks for all the tips.

I agree with using a format that is supported and I am fine with that, the biggest thing for me would be the encryption which I believe java has built in. Right now the encryption isn't a huge deal because my current program doesn't need it, but my next project will.

Right now what I'm trying to learn is kind of like the best practices for saving files, and how to create unique extensions. It has nothing to do with me wanting to make a proprietary extension but rather would like to see how it is implemented and used. The other big thing is preventing my user from directly modifying their save files in a text editor and then corrupting there data, how do I work around that, do I just assume that my users won't open the file in Vi or notepad and mess with it?

[Rob Spoor]

Jesper Young wrote:

Rob Prime wrote:- use Java's serialization mechanism. Just create a settings class that implements Serializable.

Using Java serialization for saving documents in files is a bad idea. Serialization is really not suited for long-term storage of data. That's because there is a very tight coupling (a one-to-one mapping) between your Java classes and the content of the serialized files. This means that if you change your program, then old serialized files become unreadable.

Serialization is fine for temporary storage (for example for caching objects) or for transporting objects through a network, but don't use it for storing for example documents.

I disagree slightly. If you are aware of the versioning issues, and design your class well enough, you can avoid these pitfalls. But you are right that you have to be very careful; the class at least needs an explicit serialVersionUID field, not an implicit one.

[Jesper de Jong]

David Patrzeba wrote:Right now what I'm trying to learn is kind of like the best practices for saving files, and how to create unique extensions. It has nothing to do with me wanting to make a proprietary extension but rather would like to see how it is implemented and used. The other big thing is preventing my user from directly modifying their save files in a text editor and then corrupting there data, how do I work around that, do I just assume that my users won't open the file in Vi or notepad and mess with it?

I'd say: just trust your users not to mess up the files, and if they do, it's their own responsibility that things don't work anymore.

But if you want to provide protection against this, you could calculate a checksum over (part of) the data in the file and include that, and when you read the file again, compute the checksum and see if it matches the stored checksum. If not, you know the file has been tampered with.

[fred rosenberger]

I'm not sure what you mean by 'unique extension'. When you create a file, you can name it whatever you want...So I could create files called "myFile.fred" or "myfile.DONTTOUCHTHISORBADTHINGSWILLHAPPEN" or anything else i want.

[Paul Clapham]

David Patrzeba wrote:The other big thing is preventing my user from directly modifying their save files in a text editor and then corrupting there data, how do I work around that, do I just assume that my users won't open the file in Vi or notepad and mess with it?

And why is this a requirement? I have often modified an application's configuration files with a text editor, even when the application itself can be used to modify them. Basically you can't easily stop users from doing that and most of the time it isn't worth the trouble to try to stop them. There are exceptions of course, like if the contents of the file are audited and only one program has been approved to modify the contents by the auditors, but you deal with that by access controls and not by obfuscation.

[David Newton]

The bottom line is that there's no way, ever, to ensure a user can't modify your application's files, either accidentally, with or without ill intent, rendering it still usable or complete garbage. You can lessen the chances (often greatly so), but not eliminate.