On 2005-09-06 11:29, Sergey Babkin <[EMAIL PROTECTED]> wrote: >Giorgos Keramidas <[EMAIL PROTECTED]> >>On 2005-09-06 19:27, Igor Shmukler <[EMAIL PROTECTED]> wrote: >>> Perhaps, I do not get it or maybe you are do not getting my point. >>> >>> There are times when resolving would not be possible or a name returned is >>> not necessarily the one used when file was first accessed. We have discussed >>> it here and everyone agreed on that. The hardlinks or files unlinked while >>> vnode is still open are corner cases. The unlink is a bit more difficult to >>> deal with, but hardlinks are probably not a big issue. As long as we can get >>> A name, we may not even need to know THE name. >> >> Why does it make sense to get name A in the following scenario then? >> >> user 1 creates file A >> user 1 hardlinks this to B >> user 1 gets the "real name" of A >> user 2 deletes file A >> user 2 creates a new file called A >> user 1 tries to access A and gets something unexpected >> >> Corner cases and their handling *is* important. Find another way to do >> whatever it is you're thinking you can do with "the real name of a vnode". > > This particular case is easy to handle: all that user 1 needs to do is > to do fstat() after opening the file and check that the returned inode > field is still the same.
This sounds still a bit hackish. Why require that user 1 reopens the file when a) he already has an open descriptor to, for example, i-node 12345, b) reopening may have unwanted side-effects? > On the otehr hand, if there is this new interface to access files directly > by inode numbers, why bother with any names at all? That's more like it. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
