Christer Weinigel wrote:
> So what is the sane way? There are three conflicting requirements for
> NTFS-like streams handling:
>
> 1. Don't break any existing tools, everything must behave exactly as
> it does today. tar must be able to make a complete backup.
>
> 2. Should allow old tools to work on the alternate streams (i.e.
> xv file/thumbnail.xpm).
>
> 3. Should not pollute the filesystem with extra files such as
> .AppleDouble, .fork, foo:resources or foo#tar/altstream.
Tar can be updated; the format (AFAIK) already supports
named streams/EAs, but the tools do not always. What's the point
in making apps written before streams existed work with streams
unmodified? It's like trying to make stereo sound work on a mono
radio -- the mono radio is not aware of two sound channels and
reproduces only a mono signal. Ditto with color TV -- it will
display on black and white TVs, but without color -- without the
extra data channels that create the color image.
Backwards-compatible does not have to mean "the same as."
-M
> The "files as directories" way is a big deviation from how things work
> today, suddenly one can do opendir/readdir on a file
Files with streams are not directories. I would not expect
readdir() to work on them. There would have to be a different
enumerator function.
> Any comments, I've just tried to do a brain dump to see if anybody
> agrees with me or if we're still talking past each other.
:)
> Are there any other ways of doing this?
Well, the filesystem could register "I support streams" and/or
"I support EAs" with the VFS (by providing function pointers
or something), _and_ provide its preferred namespace
augmentation, ":" for NTFS, for example. After all, ":" is
not a legal file or pathname character on NTFS.
I'm not sure that second part is cleaner than Linus'
straightforward "/dir/file/stream" idea, though. It
looks like it might break the "consistency" we're
looking for, whereas Linus' idea will not.
On a side note, how many things will _break_ if ":"
is used? I.e., /dir/file:stream ?
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:34 EST