Perhaps we should realize that we are indeed comparing apples to oranges…..

For a system it is indeed plausible that there be a “creation date” which reflects the date and time that the act of adding the file to the file structure took place.

This is different than, to coin a term, the “inception date” which determines the first date that the file’s contents came into being or, to put it another way, became useful in some manner.

For example, for a digital voice recorder of the type used to document meetings, we might set an “inception date” which, for the physical recorder, could be the same as creation date. Upon copying that file to a hard drive for further manipulation we might end up with a file creation date for the day and time it was copied, whereas the “inception date” remains the one originally supplied by the recorder.

Perhaps it should depend truly on whether a file is being copied from a domain outside of the original (i.e. from a recorder to the computer) or whether the contents are acutally being authored and stored within the same domain (recorded and saved on a recorder && recorded and saved on an actual computer)

It is my thought that there really needs to be some attention paid to interoperability standards when it comes to copying, moving, or otherwise performing some “location” related activities with a file.

Of course, one should need to be able to set the “inception date” to mark the starting period of the files “data” validity.

For what it is worth, I tested CCC 3.1 using the current version of backup-bouncer (0.1.2) and 3.1 passed all the tests. Also for what is is worth, my only connexion with CCC is that I have used previous versions for backup for some time. I have booted from CCC clones and restored from them successfully. Having learnt about backup-bouncer, however, I discovered that 2.3 fails many of the tests that 3.1 passes.

This means that if you are using Tiger+, CCC may well offer a good solution. If you are using an earlier version of OS X, it may not - though differences in asr and ditto may mean 2.3 would perform better for you than it does for me on 10.4.11.

Certainly contact LaCie.

Do you happen to be in a timezone 1 hour from GMT? Reason I ask is I seem to recall that HFS (and most unices, and maybe NTFS) all keep the date stamps for files in GMT. (The times in the “ls” listing are adjusted based on your tz timezone setting). But some FAT filesystems keep date stamps for files in local time. See what the timezone setting of your lacie nas looks like?

And, this means, to Aunt Tillie, if she does a file “Get Info” and tells that pdf to “Open with” Preview instead of Adobe, the “Date Modified” changes in the Finder, even though the pdf file contents (data fork) is unchanged. You can’t undo the change of “Open with” to get back the original date, either. (Oddly enough, changing the status to locked (or unlocked) does NOT change the “Date Modified”. )

I think there are lots of Aunt Tillies who expect:

(A.) the creation date should be preserved when copying

(B.) the mod date should not change if you want to change the default application (for opening *.pdf or any other kind of files)

In Windows, A and B seem to be what happens, and this forum (and others) are full of folks who want it to “just work” as easily on the Mac. sigh…

Do your results hold true for the Windows environment?

Specifically I just did a ‘Duplication’ of all my photos (146GB!) using EMC Retrospect NFR Vers 7.5.508 on Vista Business (NTFS) to duplicate files to a Western Digital My Passport 320GB external drive (FAT32). While it was successful/error free I still received the message “Warning: The destination volume My passport (F:) does not support extended file attributes.” So I don’t know if this means all my photo metadata is intact or not.

I’m assuming N.Gray’s tool won’t work on Windows. Am I correct?

Thanks for any indications.

According to an independent backup-integrity testing tool (Backup-Bouncer: http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/ ), it successfully preserves ALL metadata.

maurits - I saw your posts on the Backup-Bouncer site: I’m aware of your time constraints, so I don’t expect a full update of the test results. But, I think it would be of great benefit if you would add a brief “update” note, simply saying that (a) some of the tools (e.g. CCC) have been updated, with much better results, and (b) a link to Backup-Bouncer.

Otherwise, people coming across this page are going to be misinformed about the current state of affairs, and might spend a fair amount of time tracking current information down.

Thanks for this great work - you really started something, and a lot of good results have come from it!

PG

N.B. I use OS X 10.4.x on G4 machines.

P.S. Thanks Maurits for this great webpage.

http://209.85.129.104/…

the relevant information is:

“It can, but that causes problems for the finder. This is all by design.

To change the folder restore behavior hold down the option key and click the preferences button. You will have an option to restore folder dates. Just be aware that you may have to reboot the machine for restored files to become visible in the finder.”

[a] Update 2006-04-26: I’ve found this post, which basically says that the clobbering of the folder modification dates is deliberate, and that there’s an obscure “secret option” by which it can be switched off. I consider such a solution not acceptable.

(GUID partition scheme, BTW, the dual boot is with Linux and I’m using rEFIt to choose OS at boot-time, since Apple so kindly withdrew BootCamp Beta in that oh-so-typical let’s-renege-on-our-advertising -promises-after-all-they’re-only-customers style.)

The clone system boots and generally runs OK but a fair few owners and permissions were wrong, including the Unix sticky-bit flags missing from here and there, and there are infuriating issues with icon associations, including the following somewhat frustrating effect (which only appears to affect certain apps):

The icons for files associated with VLC have turned, mostly, into the blank “file” default icon.

If I use file…info to change the app associated with, say, an avi file, its icon changes, If I click “change all” it changes back to the blank one, and no others change.

If I have my original system disc mounted, via a caddy, as well as the clone, then the icons appear and behave properly. Clearly the cloning process has managed to preserve a very persistent association with the original VLC icon’s inode, or that of some or other icon cache, and I’ve been unable to track it down.

I’ve tried deleting various cache files, ALL .DS_Store and Desktop DB/DF files, restarting the finder, logging out, rebooting, all the rest.

This is only vaguely related to the brokenness of asr, and any suggestions about where to look for the relevant evil cache or whatever would be highly off-topic (but very welcome via a link to a separate discussion or something)

I’m getting increasingly pissed off with Apple’s poorly documented and bewildering mess of overt, hidden, semi-hidden, inaccessible and whatever meta-data, and it comes as no real surprise to me that Apple’s own tools don’t deal properly with half of it. While unsurprising, though, it’s very disappointing, especially as they KNOW about it and have done for some time.

My asr version is 72, Tiger 10.4.11, by the way.

I wonder if my original software disc is early enough to have a less broken asr on it, and if my problems might be fixed by using that to clone my old drive to the new one?