[sjk]

Originally Posted by dnanian

Told you you'd be surprised about the ownership thing.

Yep. Fortunately a more benign surprise than discovering how deleting symbolic links with Finder can sometimes delete the target(!)

For "fun" I deleted the ~/Library/Application Support/SuperDuper!/Copy Scripts/Standard Scripts symlink (which worked okay), tried Undo, and Finder griped "The operation cannot be completed because you do not have sufficient privileges for some of the items." Whoops.

Reminds me of potentially devastating side effects of omitting the "-h" option on Unix ch{own,grp,mod} commands (OS X versions are susceptible) when symlinks are involved, which an impressive number of root-enabled Unix sysadmins don't realize as they're using those commands (often recursively). My favorite traditional example:

% ls -l /etc/passwd foo
-rw-r--r--  1 root  wheel  1374  8 Dec  2003 /etc/passwd
lrwxr-xr-x  1 me    me       11 22 Jun 16:07 foo -> /etc/passwd

% sudo chown me foo
Password:

% ls -l /etc/passwd foo
-rw-r--r--  1 me   wheel    1374  8 Dec  2003 /etc/passwd
lrwxr-xr-x  1 me   me         11 22 Jun 16:07 foo -> /etc/passwd

Now that I've let that cat out of the bag, back to topic at hand...

We looked at file access preservation but decided against it: I think that we had problems actually getting the value preserved but truthfully I don't exactly remember. But I'll add the request to the list and we'll take another pass at it in the future. (I believe that it can't be done: when we tried, it just updated the access time...)

No worries.

Smart Update is exactly like "Copy Different" with an added "erase" pass. I can't really think of any accidental "tricking" that might happen, unless you modified something, ended up with exactly the same number of bytes, modified the times and metadata so that it would look the same from that perspective, and then did a SU. In that case, it might not copy the file, since it doesn't look "different", and we don't use a file CRC to be extra super careful. (Frankly, it really isn't necessary when you're doing a single system to backup update, it'd just take an enormous amount of time and basically make Smart Update pointless.)

Is it correct that "Copy newer" will skip files with older created/modified times than when they've actually been added to the filesystem. Downloads are a good example of that kind of file so I'm careful to know how "newer" is being interpreted. But that's not relevant with SU, if I understand things correctly.

This means that there's one potential error case: if the union of the files being copied in a given directory exceeds the capacity of the drive (assuming that all the files are different), we fail because we erase after we copy. That also means that if you rename a large directory, it's possible that we'll copy the new one before removing the old, causing a disk space failure.

Got it. Quite unlikely I'll encounter that with SU on the system volume.

Hope that answers your questions! Glad you're happy with the support: it's part of what you're paying for when you -- hopefully -- pay!

Registered this morning. Smart Update was too much temptation to hold off any longer.

Issue with exclude:

The main "Backup - all files" script excludes var/db/BootCache.playlist and var/db/volinfo.database, but those files exist on the destination volume. Not sure if the original backup or the SU copied 'em since I only noticed after the latter.

Thanks for responding to my VersionTracker feedback. Hope I didn't sound like I was giving misinformation about the way script editing worked.

About the capacity check... after posting I thought of mentioning that a simulation mode would be convenient for certain scenarios with backup media storage planning, as I'm currently doing, especially when the the space rules for dealing with disk image files aren't known. For example, I tested creating a disk image of the system volume (~19GB) on another volume with ~25GB free. If I'd let that run it would have overflowed, as expected. A simulation, safely running non-inactively for an hour or two then warning that the real deal would have failed, would have been nicer than having to manually interact and abort.

And/or is it possible for the temporary volume to use space on a different volume than the image file's final destination? Several visits to the hdiutil man page have failed to reveal a way of doing that.

Whew. That covers everything and then some for today.