RE: [Summary] Meta-data/filesystem-encapsulation



> Regarding changing the filesystem, this should not be a problem.  ext2
> already supports many "attributes" (man chattr), one of which is
> "compressed".  Even though this isn't yet supported, the idea can be used.
> Add an attribute "metadata" or "extended attribute" (oops, is that too
> much OS/2?) and this flag will get set in the file's inode.  Then when
> 
	This shouldn't even be an option, unless you plan on porting ext2 to
every supported *nix as a whole, and convince all those administrators to
convert from jfs, ufs, etc. which will NEVER happen. GNOME != Linux, even
though it is being developed there. And OS/2 is fine, it has lots of good
ideas to inherit.

> Probably best is a GNOME wrapper class around fread() and fwrite() where
> the header can be automatically prepended for supported files and/or the
> dbm/flatfile be updated simultaneously.  And while the dbm/flatfile could
> get out of sync, it should be pretty easy to get something like that
> cleaned up fairly painless and easily from cron or something.
> 
	This is going to be useless on other OSes. Remember, that while
Linux is a fine desktop *nix like OS, if it gets it's due and migrates into
corporate environments it's going to need to act as though all other UNIXes
are interacting with it. You need to assume that HPUX 9, HPUX10, SunOS,
Solaris, AIX, IRIX, etc. are all interacting with Linux and the GNOME
desktop. Make the assumption even that the user's home directory is NFS
mounted off a SunOS server. Then you will be doing the right thing.

> The nice thing about HPFS as well (and I guess NTFS, too) is that the EAs
> could grow or shrink so that things like thumbnails of images could be
> stored with the file itself as an attribute.  Of course this got lost
> being copied to floppy, etc, but GNOME will have all those same problems.
> 
	The thing that people are forgetting about HPFS and NTFS is that
while they kept extended attribute data, their OSes were assuming a single
user with local context. You cannot make that assumption under UNIX.
Therefore you need to keep that data in seperate files. The next problem is
that you cannot easily LD_PRELOAD against that for all OSes, especially when
someone logs into an IRIX machine and manipulates the files from there, and
then comes back to their Solaris GNOME desktop. The linking of the metadata
file is obviously going to be broken. The best you can do is try to handle
that gracefully.

	-j



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]