On 8/20/07, erik quanstrom <[EMAIL PROTECTED]> 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
