Date: Fri, 15 Apr 2011 20:23:34 -0500 From: Daniel Mayfield <dan@3geeks.org> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: question on extended attributes Message-ID: <1A369F02-452C-4812-A461-C9A4748AC340@3geeks.org> In-Reply-To: <20110416003306.GA13853@icarus.home.lan> References: <D8E990E6-4967-4182-858F-F735650B2B76@3geeks.org> <20110416000112.GA13487@icarus.home.lan> <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org> <20110416003306.GA13853@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> rsync: rsync_xal_set: =
lsetxattr("Documents/<foo>","com.apple.ResourceFork") failed: No space =
left on device (28)
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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?
>=20
> 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.
Rsync sees it as an extended attribute, a black box as it were, and =
simply copies it byte for byte to the remote side which then attempts to =
store the (very large) extended attribute. That's where the above =
message comes from (rsync <remote>: "." . on the freebsd box is what is =
emitting the no space left message).
I fully admit that its a bit of a hack, but I'm just looking for a place =
to start within the code so I can try to allow for arbitrarily sized =
extended attributes (or at least allocate an inode for large extattrs). =
Google gives me this: =
http://lists.samba.org/archive/rsync/2009-October/024124.html which =
confirms that the size limit of the extattr is to blame. The poster =
there had a similar idea to what you described, but I'm not satisfied =
with that.
daniel=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A369F02-452C-4812-A461-C9A4748AC340>