question on extended attributes

[Daniel Mayfield]

On Apr 15, 2011, at 7:01 PM, Jeremy Chadwick wrote:

> On Fri, Apr 15, 2011 at 05:01:58PM -0500, Daniel Mayfield wrote:
>> I'm trying to use rsync and rsnapshot to make backup copies of my Mac to my freebsd 8.2 server .  When I specify syncing extended attributes as well, I get an error for any file on the Mac that has a resource fork: 
>> 
>> rsync: rsync_xal_set: lsetxattr("Documents/<foo>","com.apple.ResourceFork") failed: No space left on device (28)
>> 
>> I'd love to work on fixing this, but I'm seeing a bunch of references to UFS1 vs UFS2 in the extended attribute readme.  But I'm not sure what I'm actually using (I took the default when it setup, which says ufs2+softdep, but mount simply says ufs).
>> 
>> Can someone help point me in the right direction?
> 
> Sorry if this sounds harsh or rude, but can I ask you what exactly
> extended filesystem attributes (usually ACLs) have to do with file
> resource forks on OS X?  AFAIK they have nothing to do with one another.

OS X stores resource forks (and a few other things) as extended attributes on HFS+ filesystems these days.  Or at least that's how it presents the HFS+ concept of a resource fork to unix programs like rsync that understand extended attributes.

> Also, you're aware of how Apple solved the resource fork problem when
> archiving something in a .zip file, right?  The "_MACOSX" directory
> within the .zip.

This is sub optimal as I'd like to be able to inspect/modify the "data fork" of the file on the freebsd box too.   For example, editing files while I'm ssh'd into the freebsd machine remotely, but still preserving the icon when it gets copied back.  If I were to do as you described, I may as well setup netatalk and build a time machine style backup device.  That isn't my goal.

daniel