OS/2 extended attributes

[Allen Reese]

Yep.  I run into the losing attributes problem every day.  except that zip
stores them for me.  I run BeOS R4, which has some very nice attributes in
the file system, so I have looked at a lot of different ways of storing
attributes on network volumes.  

The major problem with the solution I outlined is that all files must be
acessed through the API.  So Joe Unix user can't go and play with
attributed files.  ;)

Allen Reese
Senior Software Engineer
Driversoft, Inc.
allen at driversoft.com

On Tue, 23 Feb 1999, Christopher R. Hertel wrote:

> Yes, this scheme has been described dozens of times before.  The problem 
> is that these stored attributes are not part of the filesystem, so they 
> are not automatically handled whenever someone messes with the native OS.
> 
> That is, I can be logged on to my Unix system and move files, directories,
> etc. around.  The Unix system will have *no idea* that is supposed to move
> the attributes stored in the database.  This messes things up.
> 
> The way to fix this is to include these attributes in the filesystem
> itself.  All access will then be done via the filesystem, and the
> attributes will travel with the files.  The only problem here is that
> attributes will be lost if you transfer a file to a filesystem that
> doesn't support them (eg., from an NTFS filesystem to a DOS floppy). 
> 
> Chris -)-----
> 
> > There is a way that you could store attributes regardless of underlying
> > filesystem.  granted it would be a long task, but once you did it you
> > caould store BeOS attributes, OS/2 Attributes or any other OS'es
> > attributes.
> > 
> > basically you take advantage of the fact the data is stored in the file,
> > and the attributes aren't.
> > 
> > then you have a database with all of the files for a dir in it, and in
> > that you store all the attributes.  or you do like Apple does, they store
> > a .AppleDpuble directory, and store resource forks in there.
> > 
> > Either way that is a very little on how to do such a thing.
> > 
> > The other part is you would have to write your own client to talk to the
> > server and store/retrieve these attributes.  ;)
> > 
> > Allen Reese
> > Senior Software Engineer
> > Driversoft, Inc.
> > allen at driversoft.com
> > 
> > On Wed, 24 Feb 1999, Christopher R. Hertel wrote:
> > 
> > > Markus,
> > > 
> > > Novell owns the filesystem space on the server and can add features
> > > whenever they want.  Samba runs on a wide variety of Unix platforms (and
> > > other platforms too).  If I understand correctly (which would be unusual),
> > > the OS/2 extended attributes are stored in the OS/2 filesystem.  In this
> > > regard, Samba is at the mercy of the local filesystem.  If there is
> > > nowhere to store these attributes, then we can't store them. 
> > > 
> > > I'm sure someone else on the list will correct me if I'm off the mark on
> > > this.  I do know that there are filesystems developed or being developed 
> > > for various Unix platforms which do have space for things like ACLs.  I 
> > > believe that there is some work being done to allow Samba to make use of 
> > > those features, if they are available.
> > > 
> > > Chris -)-----
> > > 
> > > > Hi.
> > > > 
> > > > Does anybody know if there are plans to store extended attributes
> > > > on with smb. Since Novell has managed to do so it should be
> > > > doable with samba.
> > > > 
> > > > I'd be interested in implementing eas if someone could give a
> > > > clue where to start with.
> > > > 
> > > > Markus
> > > > 
> > > 
> > > 
> > > -- 
> > > Christopher R. Hertel -)-----                   University of Minnesota
> > > crh at nts.umn.edu              Networking and Telecommunications Services
> > > 
> > 
> 
> 
> -- 
> Christopher R. Hertel -)-----                   University of Minnesota
> crh at nts.umn.edu              Networking and Telecommunications Services
>