Re: Resource Fork as Extended Attributes
Re: Resource Fork as Extended Attributes
- Subject: Re: Resource Fork as Extended Attributes
- From: Paul Nelson <email@hidden>
- Date: Thu, 16 Jul 2009 08:59:56 -0500
- Thread-topic: Resource Fork as Extended Attributes
> From: Sean Fagan <email@hidden>
> Date: Wed, 15 Jul 2009 20:22:37 -0700
...
> The attributes btree file mentioned is used for extended attributes --
> as you note, getxattr and friends. However, the difference between
> them and the resource fork is pretty large.
>
> The Resource Fork can be opened up and treated as a normal file --
> read, write, lseek, etc. You can read and write a portion of it --
> currently, it's the only "extended attribute" that can take a
> positional argument to getxattr and setxattr.
>
> The other EAs are manipulated solely through getxattr et al, and doing
> so is atomic: you write / read the entire EA, or you don't. You
> cannot use the read and write system calls on them. And so forth.
A file system can implement getxattr as a stateless read. The user level
getxattr specifies a position and size. This gets passed to the individual
file system in the universal buffer 'uio_t'. The file system can fulfill
the getxattr request using a very efficient method if it chooses to.
However you have to consider the complexity of the underlying caching
methods.
Since apps can read extended attributes in chunks, the getxattr mechanism
does not have to read the entire EA. My own network file system does not
read entire eas from a server to fulfill getxattr requests. We do support
access to all NTFS streams via getxattr/listxattr.
As for how a file system handles resource forks, that depends on the file
system design. My file system implements the MNT_DOVOLFS mount flag, and I
will get lookup requests for stuff like "foo/..namedfork/rsrc" with the
CN_VOLFSPATH flag set. This is how apps usually open a resource fork with
my FS. The dev tools DeRez is an example. Also, the Finder uses this
method when reading icon data.
However, VOLFS file systems are not the preferred way of doing things at
Apple. The underlying file system must be able to look up vnodes by
ino_t/ino64_t. You really need to talk with DTS before spending a lot of
time developing a file system. The architecture in the kernel has been
evolving rapidly since 10.4.
One other point about apple double and extended attributes. You don't have
to support all extended attributes. You can support the ones you want, and
return ENOTSUP for the ones you don't support in your getxattr. The VFS
layer will take care of storing extended attributes in the ._ file.
Paul Nelson
Thursby Software Systems, Inc.
_______________________________________________
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