On 8/30/07, jsnx <[EMAIL PROTECTED]> wrote: > On Aug 29, 2:06 am, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote: > > "jsnx" <[EMAIL PROTECTED]> wrote in message > > > On Aug 23, 1:50 am, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote: > > >> If .owners was enforced by the OS... > > > ...that could lead to a lot of 'reserved words'... > > > > Probably it should be .attributes/owner, no new added word beyond > > what would be needed for extended attributes anyway.
> That's a good idea, and I think that brings us full circle. If we allow for a > .attributes/content which is accepted by all the major tools, then what I want > to do is done. > I'm a bit confused at this point... What is this proposal and why is it > attractive? > On the surface it looks like you could get everything you want using a pair > of files to me. One to tell you the start of > the file's normal data (or the end), and the other to let you have scratch > space for arbitrary key/value pairs. > ... The proposal, as modified, provides a mechanism that can be used to add extended attributes to files, to encode existing attributes for files, and to associate all kinds of other files with given files. The attribute names (analogous to Linux/Solaris extended attributes) would all be filenames within the .attributes directory attached to the target file, and their values would be the contents of those named files. My proposed implementation, for any Unix-like system including Plan9, is to change read() on a directory to instead read from the directoryname/.data file, if it exists, or report an error if it doesn't exist. This change should cause no disruption to existing file structures or applications, since as it stands there is no purpose in read()ing the contents of a directory (these days we use walk(), getdents(), etc. instead). Almost all utilities, including "tar", would continue to do "the right thing". Probably "cp" would need to be changed so it copies directory trees as well as ordinary files. Note that there would still be "leaf" (non-directory) files under my proposal, particularly .data files and not-yet-converted existing ordinary files. If one wanted to totally convert the storage filesystem, then .data entries could be hidden and then all visible files would indeed be directories. The primary purpose is to provide support for extended attributes in a way that works within the traditional Unix hierarchical file model, without requiring extensive kludges like the Linux/Solaris implementations have. A two-file model would also require a large amount of ad-hoc kludgery to work well enough.
