Thread: Burn to DVD?
View Single Post
  #12  
Old 06-21-2004, 10:00 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
Told you you'd be surprised about the ownership thing. If you chown those files to you:staff (or whatever), it'll stick from that point forward. I think this is due to some weirdness with OS X supporting both file systems that respect ownership and file systems with ownership 'overlaid' on them for compatibility.

Basically, if it's trying to maintain compatibility, the ownership of the files on the ownership-ignored volumes tracks your own ownership. BUT, it seems that if you copy those files locally, they have some sort of wacky track-uid-and-group value in there, and they do unexpected things on a volume that respects permissions. Weird stuff.

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...)

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.)

Anyway, once the copying has been completed, we erase things that are on the backup but are no longer on the source. (This is a bit of a simplification -- we don't copy everything and then erase, it happens directory by directory, mostly, not drive-wide -- if we were making an entirely separate pass, we would have done erase-first anyway.)

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.

In neither cases does the failure result in the loss of any data, nor does it fail silently.

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!
__________________
--Dave Nanian

Last edited by dnanian; 06-21-2004 at 10:05 PM. Reason: Clarified erase pass for Smart Update. Also updated access time comment.
Reply With Quote