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

Victor Shoup shoup at cs.nyu.edu
Mon Oct 15 15:07:22 GMT 2007


This is a general topic I'm interested in, as I rely on rsync to back  
up my mac osx files
to a remote file server.  Unfortunately, the file server is a sun  
workstation, and I don't know
if it supports xattr's, or large xattr's that arise from resource  
forks, and I'm not sure if the sys admins
back up resource forks when they backup the file server to tape.

I hacked together a bit of code to deal with this ( http:// 
www.shoup.net/xattr ).
The idea is to generate "shadow files" that store all the extra meta  
data on the file server.
To avoid hacking rsync internals, these shadow files are stored in a  
"shadow directory" with the
same structure as the original.

What would be nice is if rsync supported this directly, with the  
shadow files (with names appropriately tweaked)
stored in the same directory structure.   This is essentially Apple's  
solution for dealing with foreign file systems
that are mounted locally (e.g., NFS shares or local UFS volumes), but  
this does not work at all
between mac osx and a remote file server accessed via ssh.

I've seen some rsync patches on the web that do just this, but it  
would be much better if it were in the main rsync source.

    -- Victor Shoup


On Oct 15, 2007, at 6:13 AM, Wesley W. Terpstra wrote:

> 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.
>
> -- 
> To unsubscribe or change options: https://lists.samba.org/mailman/ 
> listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart- 
> questions.html

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


More information about the rsync mailing list