Messages in this thread | | | Date | Sun, 1 Aug 1999 18:14:53 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Your backup is unsafe! |
| |
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.
- 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/
| |