Disgusting indeed, but it might even work with no changes to 9P; it might confuse some clients, but doesn't sound easily doable given some basic naming conventions (of course, then you lose the possibility to cd into that dir and run ls there, which is the main reason I thought an extension to the file name would make more sense)
uriel On 9/2/07, Joel C. Salomon <[EMAIL PROTECTED]> wrote: > On 9/2/07, Uriel <[EMAIL PROTECTED]> wrote: > > And actually, I think one could have something similar to Douglas > > suggestion in Plan 9 without changing the kernel or the vfs, or even > > the file servers, just have a stackable file server which for every > > original file /foo.txt allows you to access a /[EMAIL PROTECTED]/ > > dir where all the extended attributes or whatever can live, that would > > even keep backwards compatibility with all existing tools (tools that > > don't know about @extendedjunk/ dirs would not even see them unless > > they explicitly walk to them, so you could use cd > > /[EMAIL PROTECTED]/, followed of ls and cat to inspect the > > attributes, but if you do cat /* or ls / you would get a sensible > > output. > > Or how about this: Just as you don't need read permissions on a > directory to walk it -- so long as you know the name of the file you > want -- how about 9p allowing walks to ordinary files. /foo.txt will > exist, and reads work as usual, but /foo.txt/metadata.xml (of course > it's all buzzword-compliant XML!) can be walked to and manipulated. > Disgusting, eh? > > --Joel >
