This limitation is one of *nix not understanding, or at least not
supporting sanely, the concept of multiple namespaces for the same data.
vfat LFN/8+3 naming isn't a matter of sym/hard links, but one of a
filesystem with two namespaces.
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.
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.
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/