From owner-freebsd-hackers@freebsd.org  Wed Nov 11 10:57:04 2015
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00FAFA2B80E
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Wed, 11 Nov 2015 10:57:04 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 6F4361A35
 for <freebsd-hackers@FreeBSD.org>; Wed, 11 Nov 2015 10:57:03 +0000 (UTC)
 (envelope-from kostikbel@gmail.com)
Received: from tom.home (kostik@localhost [127.0.0.1])
 by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tABAuwWr078065
 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
 Wed, 11 Nov 2015 12:56:58 +0200 (EET)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tABAuwWr078065
Received: (from kostik@localhost)
 by tom.home (8.15.2/8.15.2/Submit) id tABAuuaf078063;
 Wed, 11 Nov 2015 12:56:56 +0200 (EET)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
Date: Wed, 11 Nov 2015 12:56:56 +0200
From: Konstantin Belousov <kostikbel@gmail.com>
To: Ivan Radovanovic <radovanovic@gmail.com>
Cc: freebsd-hackers@FreeBSD.org
Subject: Re: Detecting new file name after receiving kevent's NOTE_RENAME
Message-ID: <20151111105656.GX2257@kib.kiev.ua>
References: <5641A2A5.7070909@gmail.com> <20151110081421.GL2257@kib.kiev.ua>
 <56426054.2070007@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56426054.2070007@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
 autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 10:57:04 -0000

On Tue, Nov 10, 2015 at 10:23:32PM +0100, Ivan Radovanovic wrote:
> On 11/10/15 09:14, Konstantin Belousov napisa:
> >> >I am wondering is there some more clever way to get this new name
> >> >(kernel is obviously aware of it, otherwise it couldn't notify
> >> >descriptor about rename)?
>  >
> > The most correct way is to use sysctl kern.proc.filedesc and look
> > for the path of the given file descriptor. This is inefficient since
> > kern.proc.filedesc returns information about all opened files for the
> > process.
> 
> Unfortunately it seems that this method (at least using 
> kinfo_getfile(3)) doesn't work - as soon as file is renamed kf_path 
> returned contains only zeros. Shame, it sounded like perfect solution 
> for the problem...

It is up to filesystem to cache or not cache the file name entry.
If filesystem does not insert the name entry into namecache on rename,
there is nothing which could help vn_fullpath(9) to return a path.

OTOH, I do not see a reason why filesystems could not be changed to
start caching the renamed file name consistently.