Date: Wed, 7 Sep 2005 14:32:34 +0300 From: Giorgos Keramidas <keramida@freebsd.org> To: babkin@users.sourceforge.net Cc: Dag-Erling Sm?rgrav <des@des.no>, freebsd-hackers@freebsd.org, Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru> Subject: Re: Re: vn_fullpath() again Message-ID: <20050907113234.GE7415@orion.daedalusnetworks.priv> In-Reply-To: <11338458.1126024159573.JavaMail.root@vms171.mailsrvcs.net> References: <11338458.1126024159573.JavaMail.root@vms171.mailsrvcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-09-06 11:29, Sergey Babkin <babkin@verizon.net> wrote: >Giorgos Keramidas <keramida@freebsd.org> >>On 2005-09-06 19:27, Igor Shmukler <shmukler@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050907113234.GE7415>