TimeVault server doesn't let go of catalog.db while idle
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
TimeVault |
New
|
Undecided
|
Unassigned |
Bug Description
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.
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.
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.