TimeVault server doesn't let go of catalog.db while idle

[Andrew Stromme]

As soon as the database file is opened up by TimeVault it is not closed until the server exits (in particular when the Database class is destroyed). This makes it impossible to remove the drive or unmount the filesystem that TimeVault is storing backups on without first shutting down TimeVault. This is a problem because normal users shouldn't have to drop into the command line to execute something like sudo /etc/init.d/timevault stop just to unplug their drive. This problem is made worse because timevault is started at boot by default.

Now that we have a framework (in the timevault-external branch) to tell us when the backup drive is present or not we should be able to check for that before any database writes or snapshots. When the snapshot or query is finished timevault can close the database connection, letting go of the catalog.db file. Then, a user can remove their external drive whenever TimeVault is not actively saving something. Upon the next dbus wakeup of the server the user would be notified to plug in the backup drive if they want to continue with snapshots/backups.

[Daniel Stiner (danstiner)]

Basically you're thinking to close the database file unless we really need it? Sounds sensible, and I think it will work very well. When the database IS in use, will it not make the drive "busy", as nautilus puts it? When any program has any file open on a device, does not HAL refuse to unmount it? Then again, between file and database writes, the drive would be quite hard to remove.
Its a step in the right direction though, and without direct HAL integration, I think it is the best possible solution.

[Andrew Stromme (astromme)]

Yes, that's what I'm thinking.

On a side note, I looked around for a while regarding what exactly happens when a user tries to unmount a filesystem using nautilus/hal. I can't seem to find anything, but if hal did send out a signal to apps saying something like "close files on the device now, we need to unmount it" then TimeVault could honor that. This would fix our problem because it would be user controlled.