[openbeos] Re: Attribute support on foreign OS (was Re: Storage Kit)

  • From: François Revol <revol@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 04 Nov 2001 17:57:41 +0100 (MET)

Yeah, that's interesting, btw we could also extend the BeOs dosfs driver
so it supports this attribute implementation, so we could keep them when 
migrating data through FAT drives :)
One has to define a standard layout and structure for the files so 
each filesystem understands them.
I'd suggest we use naming like
for a file called foo, and using the HIDDEN flag on FAT drives.

Ok, now back to OBOS (I think it's what this list talks about, not sure 
though :D) this can be implemented apart I think.

See you all,

En réponse à "Alexander G. M. Smith" <agmsmith@xxxxxxxx>:

> > The problem is Linux doesn't support attributes _at the VFS layer_.
> > So we could add attribute support on say XFS, how would we tell the
> > XFS to read an attribute from foo.txt since we must speak to the
> > VFS which doesn't know what an attribute is ?
> > 2 solutions I see for that:
> > - patch the Linux VFS to add attribute support: well, dunno if
> > Linus will like it. -> Depends on Linux maintainers.
> > - use something I myself never really have used in coding, the
> > IOCTL call.  the IOCTL is there to "perform a variety of control
> > functions on devices and STREAMS".
> My idea of a quick and dirty yet effective hack would be a dummy
> file system which supports attributes and other frills as extra
> files in a real file system.  Much like the *.info files attached
> to Amiga files to contain the icon and parameters.  Querying
> attributes and the other extra operations would be done through
> Ioctl operations, and yes, we'd need a standard set of opcodes
> for those operations.
> The runtime library would have stub functions that map BeOS
> style API calls into the appropriate Ioctl operations.  So,
> not much would change for user level programmers, just the
> addition of a BeOS compatability library.
> - Alex

Other related posts: