From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 7 11:32:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46FD716A41F for ; Wed, 7 Sep 2005 11:32:39 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D9E943D46 for ; Wed, 7 Sep 2005 11:32:38 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j87BWZCD013751; Wed, 7 Sep 2005 14:32:35 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) by orion.daedalusnetworks.priv (8.13.4/8.13.4) with ESMTP id j87BWZ2k007662; Wed, 7 Sep 2005 14:32:35 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by orion.daedalusnetworks.priv (8.13.4/8.13.4/Submit) id j87BWYQ4007661; Wed, 7 Sep 2005 14:32:34 +0300 (EEST) (envelope-from keramida@freebsd.org) X-Authentication-Warning: orion.daedalusnetworks.priv: keramida set sender to keramida@freebsd.org using -f Date: Wed, 7 Sep 2005 14:32:34 +0300 From: Giorgos Keramidas To: babkin@users.sourceforge.net Message-ID: <20050907113234.GE7415@orion.daedalusnetworks.priv> References: <11338458.1126024159573.JavaMail.root@vms171.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11338458.1126024159573.JavaMail.root@vms171.mailsrvcs.net> Cc: Dag-Erling Sm?rgrav , freebsd-hackers@freebsd.org, Sergey Uvarov Subject: Re: Re: vn_fullpath() again X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 11:32:39 -0000 On 2005-09-06 11:29, Sergey Babkin wrote: >Giorgos Keramidas >>On 2005-09-06 19:27, Igor Shmukler 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.