PATCH: preserve osx creation-date (was: Using pre2 for backing up a mac)

[Wesley W. Terpstra]

On Oct 15, 2007, at 12:13 PM, Wesley W. Terpstra wrote:
> On Oct 15, 2007, at 1:55 AM, Wayne Davison wrote:
>> The name of the attribute was changed to com.apple.crtime96 (for  
>> the moment) .  Since it is not an official com.apple.* value, I  
>> didn't want to use a name that Apple might choose in the future.   
>> The name should probably go in the rsync.* namespace, but I'd need  
>> to move the code for reading and writing the value out of lib/ 
>> sysxattrs.c into xattrs.c to do that (I believe).
>
> Yeah, I suppose it should go in the rsync namespace too.

I notice that rsync is starting to converge towards a particular use  
of xattrs:
Copy meta-data that has an analogous concept on the remote host.
If -X is specified, copy anything that has no analogue into an  
extended attribute.

In looking over the bsd flags patch, I notice that it is relatively  
complicated and still doesn't move the data into an xattr on a system  
which has no support.

I wonder if the right command-line options might be something like this:
-X ... enables copying of user extended attributes
--flags ... enables copying of bsd flags
--osx (or similar) ... enables copying of osx related meta-data  
(ResourceFork/FinderInfo/CreationDate)
-A ... enables copying of ACL information

-M ... maps any unsupported meta-data into an extended attribute on  
the remote side (in the rsync namespace)
-Q ... silently drop unsupported meta-data

I'm not sure if --flags and --osx should be implied by -p, but I  
think so.

Then, use a pseudo-design pattern where every type of meta-data rsync  
can get/set has do_{get,set}_{acls,flags,owner,group,...}. A platform  
also provides a sys_supports_{acls,flags,...}(filename). This returns  
true/false if the meta-data is supported for that file (filesystems  
differ, as do platforms). Then, if the method could ever return true,  
the platform must provide matching sys_{set,get,could_set}_.... 
(filename) methods. could_set reports if there are sufficient  
permissions for the operation to succeed.

A design pattern like this could be used to easily extend rsync  
whenever new types of meta-data appear. For each piece of meta-data,  
the do_{get,set} methods look like this:

do_set_X(file, ...):
if (sys_supports_X(file)) {
  if (fake_super and NOT sys_could_set_X(file)) {
     return set_xattr(file, X, ...)
   } else {
     return sys_set_X(file, ...)
   }
} else {
   if (-M) {
     return set_xattr(file, X, ...)
   } else if (! -Q) {
     warning: meta-data X is unsupported on platform Y for file, use - 
Q to silence this warning, or -M to map it into an xattr.
     return
   }
}

do_get_X:
if (sys_supports_X(file)) {
   if (fake_super and NOT sys_could_set_X(file)) {
     return get_xattr(file, X)
   } else {
     return sys_get_X(file)
   }
} else {
   if (-M) {
     return get_xattr(file, X)
   }
   if (! -Q) {
     if (exist_xattr(file, X)) warning: discarding meta-data X that  
was stored in an xattr
   }
   return nothing_to_sync
}

Real implementations would be complicated by meta-data that is  
partially convertible. For example, file permissions and ACLs. But  
logically, from a user point of view, one wants the above behaviour.

What do you think?