Changing time zones confuses Retrospect

[Mussauman]

When I moved from Finland to Australia, Retrospect decided that every file was modified since the last backup. It looks to me as though this is a bug from way back when HFS+ was introduced, related to HFS+ storing dates as UT rather than local, as it was under HFS. Is this correct? If so, is there any plan to fix this? I don't want to have to do complete backups every time I change my time zone. Or is it something else? I'm running Mac OS X 10.2.3, with Retrospect 5.0.236 (although I think I updated to 5.0.238, but it doesn't show up in the Get Info window).

[AmyJ]

Matching is the scheme for comparing file attributes to determine whether files are identical, which then allows intelligent copying to avoid redundancy.

 

If one of the criteria has been changed, Retrospect will back up the file again. On a Mac, Retrospect looks at name, size, type, creator, creation date and time, modify date and time, and label.

 

If changing time zones is changing file dates in your system, Retrospect will backup all files again.

 

 

[Mussauman]

Quote:

---

Matching is the scheme for comparing file attributes to determine whether files are identical, which then allows intelligent copying to avoid redundancy.

 

If one of the criteria has been changed, Retrospect will back up the file again. On a Mac, Retrospect looks at name, size, type, creator, creation date and time, modify date and time, and label.

 

If changing time zones is changing file dates in your system, Retrospect will backup all files again.

 

 

 

---

The question is, though, how Retrospect defines the date and time a file has been backed up. Is it local time or UT? Is the time stamp in the backup in the same form as the system time? If it's local, is time zone going to be taken into account? If not, then all backups will back up every file twice a year, at the beginning and end of summer time (or maybe only once, depending on how matching is implemented). Sorry that I'm still puzzled about this one.

[Syzygies]

There is a tech note on the Dantz site dating to Mac OS __EIGHT__ describing a problem with Daylight Savings time forcing full backups. The other day, I did my first backup since changing time zones (Retrospect 5.0.238 and OS X 10.2.4), and this forced a full backup.

 

I'm among other things a Mac programmer. I hit a similar issue coding a screen resolution change, where different levels of the Cocoa environment were telling me different screen sizes. After ten minutes it dawned on me I could code off the DIFFERENCE, in such a way that if Apple ever fixed this, my code would still run correctly. I felt pretty stupid that it took me ten minutes to think of this.

 

It's possible that working with times is trivial, and Retrospect is botching it. It's also possible that the Mac OS is messing with Retrospect on times the same way it messed with me on screen sizes. If I were programming for Dantz, the first thing I would try would be to lock a small file as part of the Retrospect installation, and remember its modification time in every backup archive. Whenever I saw a discrepancy between my record of this file's mod time, and what the OS reported, I would consider the scenerio that that offset should be applied to all mod times. If applying the offset significantly reduced the number of files marked for backup, I would reason that this is impossible by chance, so these files must not need backing up. If applying the offset is insignificant, who cares?

 

This strategy is entirely compatible with also trying to intelligently handle times, time zones, and daylight savings time. It acts as insurance, covering gaffes that slip through.

[Syzygies]

Here's a more robust strategy, that doesn't rely on a reference file:

 

Hash all differences in mod times of files into a small hash table (e.g. 10,000 slots) which simpy counts the entries made. With a good hash function, all the files which didn't change will hash into the same slot, and all the files which did change will end up in slots at random. It is extraordinarily unlikely that any slot's count could be 1% of the total, unless that slot represents the modification time difference for a file that didn't change. (Think, more likely that the sun suddenly turns into a supernova; forget worrying about spilling coffee on your backup tape.)

 

Here's a variation on this idea:

 

Maintain a circular array of modification time differences (e.g. 10,000 entries) and compare every modification time difference (other than zero!) with the difference it replaces, 10,000 entries ago. Maintain a separate data structure such as a hash table to count collisions and save collision values. Again, it is extremely unlikely to get even one collision when all is well, so this code will run very fast under normal conditions. If Retrospect has botched its tracking of a time change, or has been mislead by the OS, then a particular value will be involved in a large number of collisions. By the same reasoning as before, this value is the adjustment to be applied to all mod times, before deciding which files have actually changed.

 

Both of these ideas are based on the same principle: It is astronomically unlikely that even 1% of the files on a 10 GB disk can end up modified by exactly the same time difference, to the accuracy that the Mac tracks times. Less than 1%, who cares.