On 3/30/06, Burton Samograd <[EMAIL PROTECTED]> wrote:
> > ioctl(fd, SETVOLUME, &vol); is more comfortable.
>
> I read somewhere (but haven't actually seen it implimented yet) about
> using xattrs (file system property lists) instead of ioctls and
> thought that it was a pretty interesting idea. No needing to sort
> through headers to find some badly acronimized value with no docs on
> how to use it, etc...
>
> Anybody have any comments on the xattr -> ioctl type interfaces?
Doesn't seem so bad. It opens up new questions about things like if
all xattr APIs and implementations are created equal, and they're not.
FreeBSD has one way.
Mac OS X adopted the Linux API (believe it or not).
Mac OS X's version differs in behavior from Linux's in some fundamental ways.
I found this out working with some friends on an archiver that gathers
things like Resource Fork data between mac os x revisions, at some
point you can access the data via xattrs if you wish, which changes
the amount of data that is normally storable in an xattr interface.
The other thing I didn't like about xattrs on linux is you have to
write weird looping mechanisms to make sure you have a buffer that's
big enough to hold the xattr data when reading.
example:
----
TRYAGAIN:
buf = malloc(bufsz);
if (!buf) abort(); //pretty much screwed here.
ret = listxattr(path, buf, bufsz, xattr_flags);
if (ret < 0) {
switch (errno) {
case ERANGE: // bufsz is too small.
bufsz *= 2;
free(buf);
goto TRYAGAIN;
----
And this is just to get a list of the key'd extended attributes
existing on the file. Not a nice interface if you ask me. You
basically fail upwards without being told how far off you were from
having the correct buffer size.
FreeBSD has namespaced xattrs for the SYSTEM and USERSPACE.
I'll take control files any day of the week over this mess.
Dave
>
> --
> burton samograd [EMAIL
> PROTECTED]
> kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
>
