Date: Fri, 15 Apr 2011 17:33:06 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Daniel Mayfield <dan@3geeks.org> Cc: freebsd-fs@freebsd.org Subject: Re: question on extended attributes Message-ID: <20110416003306.GA13853@icarus.home.lan> In-Reply-To: <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org> References: <D8E990E6-4967-4182-858F-F735650B2B76@3geeks.org> <20110416000112.GA13487@icarus.home.lan> <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 15, 2011 at 07:06:40PM -0500, Daniel Mayfield wrote:
>
> 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.
I'll assume you're right. With that assumption in place: OS X rsync
supports extended attributes, which when used (on an OS X client) reads
data from HFS+ extattr.
How exactly do you expect this data to be saved on a non-HFS+
filesystem, such as BSD FFS/UFS, or Linux ext2fs, or Solaris UFS? How
will rsync (on the server side, meaning the process that's actually
writing the data to a file on the filesystem) know what to do with this
data?
The only way this would be possible is if rsync had its own custom way
of saving resource forks on a remote system (they would have to be
separate files). Restoration would require that rsync know what to do
with some "specially-named files" to represent the resource fork
portion. Keep reading for an example.
> > 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.
Resource forks are a pain in the ass and have been for the past 20
years: again, they existed on the Apple IIGS (which used either ProDOS
or HFS filesystems), and the only thing that supported them aside from
the filesystem and OS itself was -- ding ding -- ShrinkIt (.shk). It
amazes me that Apple continues to use them. How do they work when you
format your OS X filesystems as FFS? I'm sure Apple has some kludge
there for it.
History lesson with validations:
The Apple IIGS (specifically GS/OS) had support for resource forks. The
only thing that could use them was GS/OS. You could use GS ShrinkIt to
save/archive something with resource forks, and it would pop up a dialog
warning you of the repercussions if you tried to restore/extract it on a
non-GS/OS (e.g. PC, and sometimes Macintosh) machine. If you were using
standard ShrinkIt (ProDOS), there was no support for resource forks.
So guess how Andy McFadden -- famous Apple II programmer -- solved this
problem with the multi-platform nulib archiver?
If a resource fork is encountered in a .shk (ShrinkIt) file, and the
platform you're restoring on is non-GS/OS, the resource fork portion is
stored as a *separate file* with "_rsrc_" appended to the filename.
Apple has effectively done the exact same thing with .zip and the
_MACOSX directory. rsync would need to mimic that functionality to
ensure cross-platform compatibility (storage and retrieval of resource
forks).
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110416003306.GA13853>