Re: Resource Fork as Extended Attributes
Re: Resource Fork as Extended Attributes
- Subject: Re: Resource Fork as Extended Attributes
- From: shailesh jain <email@hidden>
- Date: Wed, 15 Jul 2009 18:00:17 -0700
TN1150 says following:
"HFS Plus has an attribute file, another B-tree, that can
be used to store additional information for a file or
directory. Since it is part of the volume format, this
information can be kept with the file or directory as is it
moved or renamed, and can be deleted when the file or
directory is deleted. The contents of the attribute file's
records have not been fully defined yet, but
the goal is to
provide an arbitrary number of forks, identified by Unicode
names, for any file or directory."
Does that mean HFS+ now supports arbitrary number of forks rather that just 'data fork + resource fork' ? And arbitrary number of forks can be accessed by getxattr and friends ?
On Wed, Jul 15, 2009 at 12:55 AM, Anton Altaparmakov
<email@hidden> wrote:
Hi,
On 15 Jul 2009, at 03:46, shailesh jain wrote:
Are resource forks and finder metadata stored as Extended attributes on OS X 10.4+ ?.
Depends on which file system you are talking about but even on HFS+ you can access the resource fork both via the extended attribute interface and via the named stream interface.
For NTFS both are the same thing the way I implemented them on Mac OS X, i.e. when using the extended attribute system calls and when using the named stream interface (currently limited by Mac OS X to accessing the resource fork only) you both times get to access the NTFS named streams.
The difference is only in the API and associated semantics with the biggest and most important difference being that using the extended attribute interface provides atomic access, i.e. you can only get/set an entire attribute (exception: resource fork where you can use an offset for partial access but this is a horrible kludge), whilst with the named stream interface you get to access the attribute on a per-byte basis just like when reading/writing a normal file.
Also, what is best way to handle resource forks and metadata, if the file is going to be transferred on different file systems (NTFS, ext3 etc) and back ?
-- Interconversion of Streams (NTFS) <-> Resource forks
The NTFS driver on Mac OS X will automatically store the resource fork in appropriate NTFS named stream. The name and syntax are stored in a 100% compatible way with the Services For Macintosh available on Windows to provide compatibility on that front as well.
-- Storing Resource forks, Streams, as Extended Attributes ? (This will limit the size and lead to
shocking user experience)
Depends on the file system. Some file systems have very limited EAs in their metadata format whilst others are not limited. This limitation is only one of the reasons I decided to use NTFS named streams to store Mac OS X extended attributes as on NTFS the total number of all extended attributes and their metadata is otherwise limited to 64kiB which is very small!
-- Apple Double format ?
Urgh. I would stay away from that if possible to provide native storage. If not then I guess it is better than not having it.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden