A while back I wrote something for Dropbox users on OS X called Dropbox Cache Cleaner. It was early in the life of the now infamous file sharing/syncing service and they had an effective but rudimentary method of caching deleted items in the event you really needed them back. The trouble was that it could consume large amounts of disk space without you even knowing it.

The awesome service managed to get even more awesome with the introduction of a much improved caching mechanism that uses a SQLite database for both configuration information and very discrete data on the files you are currently sharing/syncing and that you have shared/synced. All this is stored far away from your main Dropbox folder, virtually out of sight from all but the most inquisitive users.

I'll be using the simple/elegant Base app from Menial Software to view the various tables & data elements. (It's a virtual steal at £10.00 if you do anything with SQLite databases.) A word of caution: be careful not to mangle the data as you could end up having to re-install the app and re-sync your Dropbox if you mess things up too much.

To view your hidden Dropbox folder on OS X, Hit Command-Shift-G in the Finder and enter ~/.dropbox:

Your view should look something like this:

To view the ".db" files, just open them with Base.app which can be done by dragging the files from your Finder view to the Open File dialog view. You will see the tables that are housed in the database on the left and the actual table schema (definition) and data (contents) on the right.

Configuration data for the application & service (pretty much what is in your Dropbox Preferences) lies in the config table:

Much of that data (I have deliberately not shown mine) is encrypted with what appears to be a variant of the crypt() routine and proved to be pretty easily decipherable if you have the right tools.

The file_journal table holds what would have been the old cache information. It also appears to contain the information on your currently active shared/stored elements.

The block_cache appears to be a very intelligent mechanism for identifying duplicate files or pieces of files.

If you have ever shared a large-ish file, only to have it synchronize instantly, you have experienced one of the performance improvements of the service in that it uses the unique hash information from the shared elements to see if the data already exists on their servers. If the data is already there, you just get a pointer to it as a reference in their main database. There is no need to waste upload bandwidth (which actually costs Dropbox real money even though it is - most likely - free for you).

If I get some feedback wishing to learn more about the details of the contents of these tables, I'll throw another post together, but I wanted to go into at least a little detail to show why my once-handy utility is no longer needed. Unless you have deliberately found a way to not have Dropbox update itself (which it does without your intervention), you will no longer be using the old method of caching and, hence, there is no place for my utility in this ever-changing digital landscape.