> * (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. > > * 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? > 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. - erik
