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

Re: [Slightly further OT] Re: Spaces in filenames [was: Has a Debian developer ever unintentionally wiped out user files like Apple?]



-----BEGIN PGP SIGNED MESSAGE-----

"Keith G. Murphy" <keithmur@mindspring.com> writes:

> This points up something I've thought for some time: perhaps it would be
> A Good Thing for a filesystem to have a place for descriptive and other
> file metadata.  Folks usually use long names because they have a desire
> to *describe* the file.
> 
> Apparently, NTFS already does something similar.
> 
> Are there any free file systems that do?  It looks like ReiserFS is
> moving in a direction that would let you do this (among many other
> things).

You are refering to extended attributes.  Most EAs I'm familiar with
use a key/value system where the length of the key or value are
limited to some degree (I think HPFS was 64K for instance).

SGI's XFS (on Irix and Linux) has support for extended attributes.  I
haven't looked at what user-mode tools may support it.  Reiserfs
doesn't include EAs but you can read about the plans for it in the FAQ
at http://www.namesys.com/stream_ans.html.  JFS *should* have EA
support since it is essentially a port of OS/2's JFS.  Umm. nope, just
checked.  EAs are in the JFS todo list and are "longer term work
items" so may not happen anytime soon.

And, of course, every filesystem would have it's own way to access the
EAs.  No unified user-mode tools until that is resolved.  The proposed
method for Reiserfs looks interesting and should not *require*
user-mode tool changes.  

You can read (high level) about XFS's EA at
http://oss.sgi.com/projects/xfs/features.html.

You'll find that it allows up to 64K of binary data per attribute.
There are user available attributes and system attributes.  System
attributes are only available to privileged users and contain data
like ACLs and HSM stuff.

- -- 
- -rupa

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface

iQEVAwUBO+hiAXHDM4ucEopdAQFuwgf9G9zoTJcxzjGiPCHLV8QPxOoDi/6/tEYe
m7c836waoM9qHdXaO19WB/ubkuyBjVZ18SVrf0yIZgFhfHn8hdTw1hXpzBs/hm06
Rx0Ugno6L7Jly/6cJXvaicMXnL8SbN47X0d1d86go37hnNdhHnbu1/hnBzyO3mNj
V0Oc0gIrUvSqjdOFJVSQuUDfcFbGhvUdwx5+FpPXbsKplXfsVE58JSISwVQAwSYE
fzPlkho9SPt2WtZXhRuFJHkFMa105+ROn1oMJNpLExWLdSUO7PvJOscBgHKv6YFg
WPEStWb4ECbBeclRLswvhhtZmAiXScY+y6T3GU/4xHZnCrBJiA+FzQ==
=n0kq
-----END PGP SIGNATURE-----



Reply to: