Chronosync woes

Latte Other Software & Development
1

Hello all,

I have been running my MacBook Air for a year without backing it up, so while I was back in the UK I bought an external hard drive (La Cie Mini – portable) and set up a partition on it for use as a bootable back up of the MBA.

Since I can’t afford another licence for Synchronize! Pro X, I opted for Chronosync, as that seemed to have the support of many on this forum, especially the sainted AmberV. I made a full, root backup of the MBA hard disk into the partition and it went well … I was running 10.5.8 at the time.

Having installed 10.6.1, upgraded all the apps as necessary and available, and all being pretty much well with the system and apps on the MBA – except for the fact that the Synchronize! Pro X bundle appears as an empty folder under SL, which I’ve got to get in touch with Qdea over! – I wanted to update the backup. So I set it to run last night.

What happened is that it kept hiccuping on files related to the system and various apps, for which it said there was a “date regression”. How the hell can the files following an update to 10.6.1 have an earlier date than the files under 10.5.8? In brief, I said go ahead each time, 'cos essentially I want a clone of the internal HD, whatever the dates are in that. But I couldn’t sit up all night, waiting for it to ping and ask me what to do time and time again. And by the morning, it had updated some 222,000 files (only). It doesn’t help that being an MBA I’m having to do it over USB, not Firewire.

Something else which irritates me is that it doesn’t tell you the total number of files it is going to update. As it reads each folder in turn it increments the number of files to be updated, but it never gives you a total or an estimated time … unlike Synchronize! Pro X. So I had to abort the back up, as I needed to use the MBA today and now I no longer even have the original Leopard backup.

So, those of you who believe in Chronosync – in my mind it is “Chronicsync” at the moment! – what do you recommend? How am I to get round having to sit for a whole night and more waiting for it to tell me that there is another date regression. Having bought it, I can’t afford to throw it away. I have an unlicenced copy of SuperDuper to make sure the MBP is backed up until I get myself sorted out with Qdea, and that did the job well enough, though being unlicenced, it will only erase the appropriate backup partition for the MBP and re-copy the whole lot … I think it comes to something like a million files! But it worked without hitch. Is the only thing to do to zero the relevant partition on the La Cie and tell it to back the whole of the MBA hard disk up all over again?

Thanks for any advice.

Yours in a chronic grump!
Mark

2

Let’s talk about files, and time stamps. Files have several time stamps. The more common ones are:

  1. Last modified
    2, Last access
  2. Creation
  3. Archive

This information can be forced to a specific value very easily (a simple shell utility called touch is one way). When you are running an installer, it is very likely, almost a certainty, that the installer is forcing the various time settings to specific values. This means that your upgrade to 10.6 might have actually set times on existing files to a date older than the 10.5 file by the same name. It is possible.

What is really fun is when an installer sets times to be in the FUTURE. Then you get to have all kinds of fun issues to chase down.

Let me know if this does not make sense.

3

Lets talk about backup strategy. A “best practice” method for backup is keep like backups on a common media. For example, TM keeps all your backups managed by TM on a single drive. The “like” qualitative here that TM manages the backups. The “like” qualitative can refer to many different things. Some of the “like” qualitatives that we use are:

  1. Server farm units (all part of the same farm)
  2. OS type
  3. OS version
  4. Hardware platform/architecture

In your case, I would suggest that the 10.5 to 10.6 upgrade is significant enough that you might want to consider using a new backup medium. This might be a new external drive, a new partition on an external drive, or some other “new location”.

All of that to say that your best bet is probably to follow your own suggestion and answer yes to

Sorry.

4

Thanks, Jason.
I don’t think I had this problem when backing up any previous versions of OS-X using Synchronize! Pro X. That did also throw up the occasional error or conflict, but it had a button to “Ignore all similar” issues. I guess I’ll bite the bullet and do as you say, zero the partition and do a completely new backup. Looking at it your way, it is probably right to do a completely new, clean backup following a major system upgrade.

However, I still remain puzzled as to how doing an upgrade to more recent versions of the operating system and software apps can result in a considerable number of creation date regressions. And I would still wish that Chronosync would show how many files in total will have to be updated and an estimate of how much time it’s going to take. Mind you, I notice SuperDuper doesn’t do this either, though it does give a task list and ticks off each element in it as that part finishes.

Thanks for your help.

Mark

5

Read the first post (I know, it looks like a double, but there really are two posts there).

Now that you have read up on time stamps let me propose the following time line.

  1. Leopard is released.
  2. Snow leopard starts off as a snap shot of Leopard.
  3. As folks work on optimization in SL, file ZZZ is modified.
  4. Testing of SL show ZZZ is absolutely wonderful and binary image is frozen.
  5. Over in Leopard land ZZZ has a bug in code that is optimized out of SL in #2.
  6. Fix for #4 is released as 10.5.Z
  7. SL is released using image binary image of ZZZ created in step 3.

Consider that this is a normal release flow and then add the whole concept of “multiple time stamps” for files in OSX and you might begin to wonder exactly how it is you have escaped this error for so long.

For the record, this type of time stamp error is not uncommon in my line of work. We get them by the server full after every patch cycle. Oracle is probably the worst offender if you ignore M$.

Anytime. Just don’t get to used to it. I figure that anything that I do that helps is purely accidental. I wouldn’t want you to be disappointed in the future.

6

I don’t know how I missed that one! When I came back to the thread it went straight to your second post.

Actually in the meantime I had worked this out for myself in relation to the launch of SL after a good year of development work, vs the incremental upgrading Leopard. But it still seems a bit odd in terms of apps: let’s say you have wagadoogoo.app version 1.4 running on Leopard. SL comes out and there is a bug with 1.4 under SL, so an upgrade version to fix that is launched, wagadoogoo.app version 1.5 … and that has creation date regression on some of its files too, even when it’s only taken a couple of weeks to make the fix? Never mind, the ways of the computer industry are mysterious … without even having to think of M$!

Don’t be so modest! When it comes to this kind of thing I have found your posts unfailingly helpful, and your other posts and banter with Vic-K and others amusing. Oh dear … I’m going to have on of Vic-K’s personas on my back now!
:smiley:
Mark

7

Once one of the vic-k-ites starts in on you it is all over.

Believe it or not there is a simple explanation for how 1.4 -> 1.5 is nothing like 10.5 to 10.6. Ready? The 10 doesn’t count in OSX. So you didn’t go from 10.5 to 10.6 but from 5.8 to 6.0. Big deal.

Actually it is. 6.0 was started back in the days of 5.2. When 6.0 was started the source tree was branched (forked is more accurate) and any changes to the code base would need to be merged into the 6.0 branch. This would be like an editor working from a manuscript while you were still writing your book. Should work OK as long as he updates his copy with all your changes. Think both of you making changes at the same time. This is common in software development (except in small houses like L&L were there is only one person).

Now to see where your specific problem comes in, imagine that the editor takes 2 chapters and collapses them into one. Now you make a couple of changes to your copy but he has no place to merge them. Even worse, the changes are “with out value” for the end release. Would he change his copy?

Now imagine that each chapter in the book is a separate file. Not only did the editor not change his copy of chapter Q, he never updates the file to indicate that this one is actually newer than your version of chapter Q.

All this is the long way of saying that the file in OSX SL that is “older” was simply never modified in the SL branch since the last SL build. Yet that same file WAS built more recently as part of a Leopard update. The binary distribution methods used today make this error very easy to create.

Now that you have wasted more time than you care to admit reading this longwinded post, you need to find me a real, a traditional recipe that will use my bean curd (extra firm), bok choy, and chinese broccoli. Extra ingredients are acceptable, but I have to use these three up before they go bad on me.