From owner-freebsd-hackers@freebsd.org Tue Nov 10 09:20:19 2015 Return-Path: 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 BC1A1A2AB8A for ; Tue, 10 Nov 2015 09:20:19 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5186E102B for ; Tue, 10 Nov 2015 09:20:19 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: by wmec201 with SMTP id c201so105061600wme.1 for ; Tue, 10 Nov 2015 01:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=45oXpxFJ32MsbQblZqiX0LkVqK8BjzuivVd/Hiy6FsY=; b=s8SgYU5Xg5+mgt2er3gGsilP/VcaGCdSPW4cZuQ01vyFkwlEV/1PCdv5j2sJsMbvm8 wpqyYxWbXdYMxuVQ1UekZhjKvcJO/h/5Y8HmfqYxVAupVrFeR0w3PncEVklvj0ibSxr+ wMKw9tK3DzYJLI1DpmbCswZygHAZeBzqzQ4hAvPC5oydUWkiJUXQxPc4xkSK/etPNgi8 jqL8HDB+7ELKzaIR97TsfIdlWTF521Ia5kZTWBRIXFfUE0pEsAj5ntXnwF3aHX42vJE4 UZB75Ui1oSu5bX64AenflVSorZkf/7GQHOUElgVXrzjK8cKR7a7gp8cZ3jnq06TVC9U2 /OTQ== X-Received: by 10.194.90.98 with SMTP id bv2mr2664685wjb.78.1447147217551; Tue, 10 Nov 2015 01:20:17 -0800 (PST) Received: from zmaj.softwarehood.com (93-87-243-129.dynamic.isp.telekom.rs. [93.87.243.129]) by smtp.googlemail.com with ESMTPSA id iw8sm2434509wjb.5.2015.11.10.01.20.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Nov 2015 01:20:16 -0800 (PST) Message-ID: <5641B6D0.4070207@gmail.com> Date: Tue, 10 Nov 2015 10:20:16 +0100 From: Ivan Radovanovic User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130812 Thunderbird/17.0.8 MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-hackers@FreeBSD.org Subject: Re: Detecting new file name after receiving kevent's NOTE_RENAME References: <5641A2A5.7070909@gmail.com> <20151110081421.GL2257@kib.kiev.ua> In-Reply-To: <20151110081421.GL2257@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 09:20:19 -0000 On 11/10/15 09:14, Konstantin Belousov napisa: > On Tue, Nov 10, 2015 at 08:54:13AM +0100, Ivan Radovanovic wrote: >> What is the best practice for discovering new file name after receiving >> kevent(2) NOTE_RENAME on its descriptor? >> >> At the moment I am storing fileno from dirent(5) structure together with >> descriptor and name, and when I receive NOTE_RENAME I re-read directory >> and use it (fileno) to discover new name, but this obviously requires >> re-reading entire directory on each NOTE_RENAME. > NOTE_RENAME means that the file backing the given file descriptor was > renamed, not that some directory entry in the contained directory > renamed. In particular, the new dirent for the file, for which you get > the notification, may belong to some other directory. As such, scanning > the directory which contained the file before rename is useless. > >> >> 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. > > If somebody cares about this, she should implement e.g. sysctl > kern.proc.onefd which takes both pid and filedescriptor, to return > single fileinfo structure for given file descriptor. > Thanks, kern.proc.filedesc is super-efficient compared to what I had in mind. I assume right way to use it would be through kinfo_getfile(3).