> As far as I can see, this whole mess is a result of a fundamental
> limitation in Linux, Unix in general, and tar specifically.
>
Yes.
> This limitation is one of *nix not understanding, or at least not
> supporting sanely, the concept of multiple namespaces for the same data.
>
Yes and will not support for foreseeable future.
> vfat LFN/8+3 naming isn't a matter of sym/hard links, but one of a
> filesystem with two namespaces.
>
Yes, and it's out of Linux/*nic scope.
> Note that this is NOT limited to vfat, since a correct implenentation of
> ncpfs should understand the concept as well, since Netware supports as
> many namespaces as you want, usually LONG(lfn) + DOS, but also have FTP
> (unix style names) and MAC (apples data/resource style), which introduces
> exactly the same kinds of problems as you see with vfat.
>
Not exactly. When you mounted Novell's volume using DOS (or unix, or
whatever) namespace you CAN NOT use name from other namespace to open file
or something. With vfat you can and THIS is biggest problem.
> I would suggest you try looking at the problem from this side instead,
> since it's quite fundamental to several of the supported filesystems, not
> just vfat.
>
1) Not SO fundamental.
2) Filesystems come and gone, *nix will stay
Sane support for foreign fylesystem is NOT valid reason to make
fundamental changes in *nix/Linyx filesystem design. They are FOREIGN
after all. If Linux supports them somehow -- it's bonus. Plus in most
cases just few ioctls will be enough.
> On Sun, 1 Aug 1999, Alexander Viro wrote:
> > On Sun, 1 Aug 1999, Riley Williams wrote:
> >
> > > > Wonderful. So you are going to accept the situation when
> > > > renaming one of the links makes another disappear?
> > >
> > > OK then, delete this option and replace the word "DIRECTORY" with
> > > "DIRECTORY or FILE" in option 3. I don't see the necessity for that,
> > > but if you feel uncomfortable with consistant behaviour...
> >
> > This behaviour is *inconsistent*. rename() affects *links*, not files.
> > It cannot and should not know about other links to file. Learn the OS you
> > are using, damnit. Learn the bloody difference between the link and file.
> >
> > > Try the following:
> > >
> > > Q> cd /mnt
> > > Q> mkdir a b
> > > Q> mount -t XXX /dev/fd0 a
> > > Q> mount -t YYY /dev/fd1 b
> > > Q> cd a
> > > Q> set > eg1
> > > Q> ln eg1 eg2
> > > Q> cp eg* ../b
> > >
> > > For it to be correct behaviour, the result of the last step should be
> > > INDEPENDANT of the values of XXX and YYY in the above. Anything else
> > > is BROKEN in my honest opinion.
> > >
> > > Note that arguments about the ln step failing are NOT relevant, so
> > > don't waste your time on them. This is a discussion about the actual
> > > behaviour on fs's where at least one hard link is supported, as it
> > > would be on VFAT under the proposed semantics.
> >
> > *One* link is always supported. You mean 2. Your proposed semantics is
> > *not* a semantics of hardlink.
> >
> > > On an EXT2 fs, what happens when one tries to move a file to an
> > > existing file that is marked IMMUTABLE (as I suggested above) ?
> > > Whatever happens there should also happen here.
> >
> > So you are making the files with long names immutable??? Attributes belong
> > to *file*, not *link*.
> >
> > > > If you consider the whole thing as hardlinks you should end up
> > > > with (a) Anti.... with the same contents as it used to have and
> > > > (b) foo being renamed. Great, now we have to generate a new
> > > > short name.
> > >
> > > Why?
> >
> > Because the long name survived and it bloody has an 8+3 record, thus the
> > prohibited name. If the long name doesn't survive - you got a proof that
> > those are not hardlinks.
>
> --
> Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/
> A Pentium is a terrible thing to waste, http://www.mersenne.org/prime.htm
>
>
-
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/