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

[Wesley W. Terpstra]

On Oct 15, 2007, at 1:55 AM, Wayne Davison wrote:
> On Sun, Oct 14, 2007 at 08:14:57PM +0200, Wesley W. Terpstra wrote:
>> I've attached a patch which does this. Currently resource forks  
>> and finder
>> info get placed into an extended attribute transparently by osx
>> (com.apple.{ResourceFork/FinderInfo}). This patch makes another  
>> "extended
>> attribute" called com.apple.CreationDate.
>
> Thanks!  I've twiddled your patch a bit and checked it in as a file in
> the patches dir (for now, at least):  osx-create-time.diff
>
> I changed the storing of the data to store the time value as 12  
> bytes of
> binary data -- 8 for the time_t value (for future expansion) and 4 for
> the nsec value (which always be 0 at present).

I fail to see the advantage of a binary version. You add concerns  
about byte-order and make it unreadable to a sysadmin. (I also don't  
like how the ACL stuff is binary) There was no problem with 8 byte  
time_t vs. 4 byte values with the other format either as it would've  
been good until year 9999. If stat is textual, why not this? Saving a  
few bytes is not a good reason ...

> 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 also enabled the XATTR_NOFOLLOW option for {get,set}attrlist().

This option doesn't exist for these system calls. There is, however,   
FSOPT_NOFOLLOW.

-------------- next part --------------
HTML attachment scrubbed and removed