Messages in this thread | | | Date | Mon, 2 Aug 1999 09:33:23 +0000 (GMT) | From | Henrik Olsen <> | Subject | Re: Your backup is unsafe! |
| |
As far as I can see, this whole mess is a result of a fundamental limitation in Linux, Unix in general, and tar specifically.
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/
| |