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, 22 Jul 2009 18:59:11 -0700
On Wed, Jul 22, 2009 at 2:12 PM, Mark Day
<email@hidden> wrote:
(Removing
email@hidden from the CC list)
What file system were you creating the extended attributes on, and what were the names of the extended attributes?
Yeah I created EA of greater size (8192) on a volume other than HFS+ that explains why operation succeeded (apple double format !!).
On HFS Plus, the maximum EA size is based on the node size of the Attributes B-tree. By default, the node size is 8192, which results in a maximum EA size of just over 3800 bytes. Resource forks (where the EA name is "com.apple.ResourceFork") are actually stored as extents, and can be much larger.
Hmm. Atleast TN1150 seems to suggest that B-tree node size for Attributes file is 4KB (while for catalog file it is 8KB). In any case, I was not able to calculate how EA size came down to ~3800 Bytes. (Is it that I am not supposed to look at or be concerned with other fields ?)
For volume formats that don't implement EAs themselves, the kernel provides a default implementation, storing the EAs (and resource fork) in an AppleDouble file whose name starts with "._". Taking a peek at the code, it looks like the maximum size in this case is 128 KiB.
Other volume formats will have their own size limits for EAs.
Great !
Thanks !
Shailesh Jain
On Jul 22, 2009, at 10:27 AM, shailesh jain wrote:
@Mark.
Interestingly I tried creating several extended attributes with size > 4096 bytes and it just works fine. I never enabled any flags to support extend based attributes. Is there a way you can check whether extend based attributes are enabled ?
Shailesh Jain
On Wed, Jul 22, 2009 at 9:19 AM, Mark Day
<email@hidden> wrote:
The extended attributes API is what you use to get at what TN1150 calls a "named fork." So far, we only support what TN1150 refers to as inline attributes (where the content of the attribute is stored directly in the B-tree node). The APIs are the getxattr(2), setxattr(2), removexattr(2) and listxattr(2) system calls.
As Chris Suter mentioned, there is an experimental implementation of extent-based extended attributes. But that support is disabled by default. I would suggest that you do not try enabling it yourself. If we do end up shipping support for extent-based extended attributes, the implementation could be different and incompatible with the one you currently see in the sources.
-Mark
On Jul 20, 2009, at 11:39 PM, shailesh jain wrote:
@Terry:
Except for Apple TN1150 (I haven't read in entirety), all places that I have referred wikipedia, Mac OSX internals by amit singh and private communications with other folks suggest that arbitrary number of forks are supported. (with limitations on size ? ..
so still not as full fledged as named streams on NTFS)
Ok, I failed to find on google. Is there a place where I can lookup API's to access resource forks (any number of). ( I know that through extended attribute interface, I can access resource fork) ?
Shailesh Jain
On Wed, Jul 15, 2009 at 8:15 PM, Terry Lambert
<email@hidden> wrote:
On Jul 15, 2009, at 6:00 PM, shailesh jain wrote:
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 ?
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
_______________________________________________
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