Storing Custom Data: Hidden Files

Writing Recycle Bin 2.0 allowed be to get up close and personal with the various issues that come with storing your data as a Vault file.  Like with my other articles in the Storing Custom Data series, there are advantages and disadvantages to this technique.  It's up to you to decide what is best for your needs.

Hidden Files
The idea here is that you take your data, serialize it to a file, and check it into Vault.  The file should be hidden so that it doesn't confuse end users.  This technique isn't fool-proof however, users can adjust their settings so that they can see hidden files.  So you might also want to set special security on the file so that it can only be edited by your program.

Example
For Recycle Bin 2.0, I needed a way to remember where a file came from.  That way it can easily move the file back to it's original location.  I decided to create a file called RecycleBinManifest.xml to store this information (and other stuff).

Just about every Recycle Bin command involves checking this file out, editing it and checking it back in.

Analysis
This technique is probably not a good fit for something like Recycle Bin.  Hidden files work much better if the data isn't likely to change.  But if you need to constantly change the data, you run into problems:

• Multi-user issues.  Only 1 person can run a command at a time, since only 1 person can check out the file at a time.  If you want to guarantee only 1 user at a time, this is a good thing.  But for most commands, you want to allow multi-user workflows.
• Error handling.  If something goes wrong, the file might get stuck in a checked out state.  This will effectively prevent anyone else from running the command until the the checkout is undone.  In Recycle Bin's case, the undo checkout has to be done manually by an administrator.
• Replication.  If you are running in a connected workgroup environment, your site needs ownership of the file in order to check it out.  Recycle Bin gets around this by logging in to the workgroup that owns the file.  The downside is that operations are slower on other sites.
• Historical versions.  Every edit results in a new version of the file.  This means that you constantly need to purge old versions to avoid needless clutter.  On the plus side, there may be cases where you want to go back a version or two.