vn_fullpath() again

[Giorgos Keramidas]

On 2005-09-06 11:29, Sergey Babkin <babkin at verizon.net> wrote:
>Giorgos Keramidas <keramida at freebsd.org>
>>On 2005-09-06 19:27, Igor Shmukler <shmukler at mail.ru> 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.