On Thu, 2005-06-30 at 14:47 -0400, Horst von Brand wrote: [snip] > Let me moderate that a bit: I'd be happy to have (some) files behaving > strangely, /if in exchange I get something very worthwhile/. I.e., Unix > filesystem sockets, named pipes, virtual filesystems all behave in weird > ways, but this downside is more than compensated by huge advantages (even > being able to do things that would otherwise be impossible). But all I see > is that file-is-directory advocates explain over and over how they are > bending over backards to get the whole mess working exactly like true > directories (nothing more, in the end quite a bit less). The uses I've seen > discussed don't really need files-as-directories (you get most of the > advantages by just tar(1)-ing up the contents, or packing them in some > other way; OpenOffice /has/ structured files, XML inside zipped files, Java > also uses zip files for its structuring needs, etc), or are ideas that > might be nice to have on exclusively one-user, isolated machines, like > "keep /my/ annotations/icon/application name/whatever with the file's > data", but that break down in multiuser (even serially, one user after the > other) systems or when files are shared (via network, or simply by sending > by mail or by copying from one machine to the other). In my rather ample > experience, that situation is rare today, rapidly dwindling in the arena > where Linux is mostly used. So this particular case of strange semantics > for files has no upsides I can see, only downsides. The downsides have been > discussed to death, and AFAICS there are fundamental problems with the idea > that can't be fixed or sanely worked around. So why bother? Structured files are fine when they're small but quickly become disgusting as they get bigger. Either you slowly rewrite the whole thing or you "fast save" by writing new sections to the end of it that replace existing sections. That's how you end up with documents that contain "deleted" information that was supposed to be confidential. Having the filesystem track each part for you and then creating a structured file when needed (and without needing to remember to run a special tool) is a far better idea. (reiser4 doesn't do this but its a possible idea) Another advantage to file-as-directory is being able to access all the file's meta-data through a single channel: file names and text data. It removes the need for chmod, chown, touch, getxattr, chacl and all the rest of the special tools needed to work with Unix files. It also makes it far easier to add new meta-data in the future, because no new tools have to be written to use it. So that's two reasons to bother. -- Zan Lynx <[email protected]>
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- Re: reiser4 plugins
- From: Horst von Brand <[email protected]>
- Re: reiser4 plugins
- Prev by Date: Re: reiser4 vs politics: linux misses out again
- Next by Date: Re: [patch 1/] timers: tsc using for cpu scheduling
- Previous by thread: Re: reiser4 plugins
- Next by thread: Re: reiser4 plugins
- Index(es):