Apolitically Incorrect » Upgrading from Time Drive 0.1

The Glass Ceiling When it comes to most things, starting fresh is a blessing. The reason for this is rather simple, when starting over you don’t have to worry about baggage. After all, baggage is only valuable when on holiday; otherwise, it just slows everyone down.

This is especially true for software. Over time, computers tend to accumulate a rather potent type of digital baggage that can be very difficult to get rid of. And that digital garbage results in inconsistencies that can cause enormous – and usually unforeseen – problems.

However, even though starting fresh is usually the best option, that isn’t always true. Sometimes, it’s better to risk the problems and incompatibilities. For example, starting over may mean that you destroy hours worth of customization, or that you lose work already created because the older version are not compatible with the new.

Unfortunately, the general rule is also somewhat true of Time Drive. So, if you were one of those stalwart and brave individuals who decided to experiment with Time Drive 0.1, this post is for you.

In the last few days, I have been in touch with a number of people who have experienced a number of said inconsistencies and problems. And while several of these problems ended up providing insight on mistakes made during development, some of the others were changed on purpose. That is to say, the so called “bug” was actually a feature.

After fielding a couple of particularly angry e-mails, however, I thought that it might be good do a formal write up that describes how to work around these incompatibilities. And while no one likes to squash bugs or fix things that previously worked, rather fortunately, every one of these problems can be overcome with a little bit of effort and patience.

Reset Your Preferences

Right. Now that the tone has been set, it might be good to talk briefly about the changes that caused the majority of the problems. As explained in Time Drive 0.2 overview, Time Drive has a completely new settings system. In order to support Amazon S3 and a few of the more advanced Duplicity settings, these changes were necessary; but at the same time, they introduced the aforementioned issues.

Here’s the bad news: as a general rule, Time Drive 0.2 can’t read the settings file from 0.1.0 to 0.1.5. It might try, but the results are not going to be pretty. The list below includes just a few examples:

If running Time Drive on a version of Python 2.5, you may experience sudden user interface freezes or unexplained errors.
The program might just refuse to do anything. For example, it may not let you open the configuration pane, run a backup, or a restore option.
The computer might suddenly start to lie to you, for example, it could say that a backup completed successfully when it really failed. Or that a file was restored, when instead it got sucked into some miscellaneous electrical chaos somewhere.

In all of these cases, there is only one thing to do. You’ll need to delete the old Time Drive settings file, which is found in the user configuration folder for Linux and Cygwin (Windows) users:

/home/Username/.config/Oak-Tree/Time Drive.conf

And in the Library/Preferences folder for users of Mac OS X:

/Users/Username/Library/Preferences/us.oak-tree.Time Drive.plist

After you find and delete that file, then you can launch Time Drive in the normal fashion. This will create a brand new settings file of the same name. Unfortunately, you will need to re-specify your backup location, re-add your folders or exclusion criteria, and reset your preferences. But once that’s done, you can pick up right where you left off.

Beware of Spaces

While the new preferences system is the biggest cause of upgrade problems, it wasn’t the only culprit. The next largest cause of problems happened to be us, the developers. In addition to the aforementioned “bugs” that were really features, we also inadvertently created new ones. The best example would probably be how Time Drive deals with spaces.

The underlying issue doesn’t have anything to do with Time Drive, actually, but is due to quirks in Duplicity. Put simply: Duplicity doesn’t like spaces in the backup destination. At all. It does okay when backing up to a secondary hard drive or USB drive, but that’s about it. SSH, FTP, WebDav and Amazon S3 backups will all fail. Or worse, it will cutoff the destination name at the first space, causing a raft of other problems. (/home/Jon Adams would suddenly become /home/Jon).

So … to fix this issue, we decided that we simply wouldn’t allow spaces in the backup destination any longer. For most remote connections, this was never much of an issue, since who ever heard of a space in an ftp or http url? But it did become a problem if one of your folders had a space in the name.

Let’s consider, for a second, that you added a folder named “My Documents” to your list of backup folders. Time Drive 0.1 would try and store all of the backup data at “/path/to/archive/My Documents”. If that data was sent over ssh, ftp, or webdav(s), you got all kinds of other obnoxious errors. But, if you happened to choose a local folder as your backup destination, it would work.

Time Drive 0.2.0 solved this problem by automatically replacing all spaces in the folder destination name with a dash. Thus, instead of storing your backup data at “My Documents”, it would be stored at “/path/to/archive/My-Documents” (note the dash).

But while this fixed the remote backup issue, it caused problems for people who made local backups. After the upgrade, Time Drive wasn’t might not have been able to find the previous backup sets, and would start all over again; an action that some people found annoying or confusing.

This problem has now been corrected. Time Drive 0.2.1 and later allow spaces for local backup paths. Remote backup urls will still have any space replaced by a dash, however.

Cron No Longer Works

A third very common complaint was that backup jobs through cron would no longer work correctly. Like the issue described above, this “bug” was actually a feature. For automatic backups, Time Drive uses the built-in Linux/Mac OS X cron daemon. Based upon the option that you specified, it would add then schedule itself for daily, weekly, or monthly backups and provide a link to the “timedrive-backup” script.

Well the location of that script moved. Previously, it lived in the “timedrive” folder. But in Time Drive 0.2, we changed how the program gets installed. It now uses a proper Python distutils script (setup.py) to copy the main program (time-drive) and the backup script (timedrive-backup) into usr/local/bin. The new location of the backup script results in a broken cron job.

To fix this problem, simply go into the preferences dialog of Time Drive and change the backup frequency to something other than what it is now, then, click the “Ok” button. You can then go change it back. This will cause the crontab to be updated with the correct location of “timedrive-backup”. And, like always, Time Drive on Windows doesn’t support automatic backups, since Windows doesn’t have a cron daemon.

Summary

And there you have it, three of the most common upgrading complaints. But please keep in mind, this list is far from exhaustive. Should you run into other problems, please leave a note in the comments and I will get back to with something that may represent timeliness. I may even be helpful, but as those encounters have yet to happen, overall that is yet to be seen.
______________________________________________________________

(Miscellaneous Request: When making comments, please be polite. I can certainly understand that you may be frustrated. After all, Time Drive might have just destroyed your only backup of your novel! Even so, rudeness probably not be tolerated;unless it happens to be deviously clever, that is. Cleverness and wit will always be tolerated, and may even be encouraged.)