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 10:27:32 -0700
@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