Michael Rothwell <rothwell@flyingbuttmonkeys.com> said:
> Rogier Wolff wrote:
> > Linus' suggestion of having a mix between a file and a dir is
> > interesting, but is not representable by a normal ext2fs
> filesystems that support streams/forks/EAs are _not_
> like ext2, and it seems wrong to make them try to
> squeeze into ext2's shoes.
ext2 is a POSIX filesystem. So yes, we are talking about forcing them into
(something resembling) POSIX semantics.
> , or
> > TAR. Having to extend the TAR format is a pain in the ass. Losing info
> > when you untar onto an ext2fs is also annoying.
> So there will be a "star" utility for streams filesystems,
> which one day will get merged into regular tar. Or "spax"
> or whatever.
Better build specialized tools, don't hope for interoperability. It is not
just tar(1) which is affected, it is almost every single tool tha handles
files; and then think about exporting this gunk over NFS to an uninfected
Unix system, and trying to handle it there... or just unpacking your NTFS
files on a Mac filesystem, or VFAT. Fun, fun, fun.
[...]
> It would be nice to have a universal representation
> of streams/EAs/forks for FSes that support them, without
> using ".LinuxDouble" chicanery.
The central problem is that there are just too many incompatible flavors of
EAs and streams, with different semantics, and proposed uses that add their
own twists (store a cookie that can't be messed with together with the file
(for example to record capabilities, creator, and so on), the cookie is
moved/copied around with the file (or isn't), access permissions to a
stream/EA are independent of the access rights to the file (default icon is
visible even if I can't read the file proper) or not (the multitude of
streams are a entity that has to be protected as one object).
All this has to be sorted out, defining precisely _what_ the filesystem
should do, and _how_ it maps to each of the multitude of alien filesystems
that it hopes to support, and _to what extent_ this non-standard behaviour
is filesystem-specific, _what_ (if any) changes to userland are needed to
support it (not just locally, remotely too!). Define a reasonable API.
Security implications have to be considered carefully. If that isn't done,
all this is just wishful flaming over hot air.
Easiest way out: Filesystem specific tools and libraries for hacking around
on alien filesystems supporting variants of this (IMVHO fundamentally
broken) concept. Userland-NFS like packages for exporting/importing them
as needed. World domination, fast; to sweep this whole nonsense away.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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:33 EST