Re: [9fans] Re: everything is a directory

["Paweł Lasek" <pawel.lasek@gmail.com>]

On 8/20/07, erik quanstrom <quanstro@coraid.com> wrote:
> > * (IIRC) Beagle daemon uses extended attributes to track files that
> > were scanned and are not modified - they contain part of it's detected
> > metadata, hash and DB pointer
>
> so, to summarize.  beagle is using attributes to extend the file object.
> i think the main benefit files (and a filesystem) is exactly that they
> are not objects and can't be extended.

The beagle example is the weakest, since I don't use it ( it's written
in .NET, uses a bunch of weird tools and AFAIK doesn't play well with
external storage -- shortly, I'd do it differently :D).

> >
> > * NTFS discards the Unix concept of a file entirely - what was shown
> > before as trouble with Alternate Data Streams is in fact trouble of
> > keeping backward compatibility (Internally, NT doesn't have drive
> > letters or any of the DOS stuff). A File in NTFS is a MFT entry with a
> > bunch of attributes. Those attributes have several types/names
> > defined, like DATA for file contents, one for keeping filename (for
> > which there are three namespaces: DOS8.3, Windows, POSIX), one for
> > legacy DOS attributes (used by the official, backward compatible API),
> > one for security data, and others used mostly by system daemons
> > (Although NT5+ explorer uses one to hold various comments about files.
> > Rarely used by people I think).
> >
> > I especially like the NTFS implementation, because it allows to use
> > NTFS for most Operating Systems without modifying internal structure,
> > while making it easy to add "compatibility layer"
>
> so how does one create a sensible grep utility that operates on an arbitrary
> mft entry?

I'm not WinAPI expert, so I can' tell you implementation details on
Windows, but if you are writing your own API, all you need is to open
attribute/iterate over attributes instead of fopen/fread/... As I
wrote, they weren't exactly made "for the users" and as long as you
don't put vital user data inside, it should not pose problems. The
only thing I'd add is that I think NTFS driver should allow
'open'/'read'/'write'/etc on directory with directory structure as
it's data field (directories have different type in NTFS, so they
don't have the canonical DATA field)

If attributes are used properly on NTFS, your grep question changes to
"How does one create a sensible grep for file access rights?" in
plan9/unix context. AFAIK everyone uses 'stat' for such things instead
of grepping FS structures?

The biggest problem is exactly the same as the one with Unix signals -
people make wrong use of the tools - most of the time, NTFS attributes
are only accessed through API calls for the data that is stored inside
or by FS driver itself, not directly by apps. On the other hand, it
means that I can implement a Plan 9 NTFS variant without remaking FS
structures and if I put some dummy data in MFT entries, It will be
readable (even writable) by NT, linux, etc.

> > As for things that need to work with cp/mv/others, I suggest making
> > better file formats or adding metadata in different file. It's not the
> > smartest use of Extended Attributes/NTFS attributes :-)
>
> i think you're missing the real difficulty with attributres.  the tools approach
> works precicely because files are not objects and can't be extended.
>
> if you want a system with extensible object storage and not a filesystem,
> i think you need to think about how to add the extension to all tools at
> the same time.  (or maybe you dispense with the tools approach.)  this
> doesn't seem like a promising route to me.

I said that what is put into attributes should be easily discarded
away, so while tools might support copying them, it's up to you to
specify that they should. Like the xfstools example before - none of
them use eas the way that you should need to modify basic tools (at
least i don't see any reason to use them that way).

> - erik
>

I'd sum it this way: I'm all for *wisely* used external attributes -
the trouble is the *wisely* part :-)

-- 
Paul Lasek