From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaya Potter Subject: Re: Finding hardlinks Date: Thu, 28 Dec 2006 13:13:17 -0500 Message-ID: <1167329597.5144.2.camel@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Benny Halevy , Arjan van de Ven , Jan Harkes , linux-fsdevel@vger.kernel.org, Miklos Szeredi , Mikulas Patocka , nfsv4@ietf.org Return-path: Received: from cs.columbia.edu ([128.59.16.20]:45680 "EHLO cs.columbia.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932948AbWL1S0k (ORCPT ); Thu, 28 Dec 2006 13:26:40 -0500 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2006-12-28 at 09:58 -0800, Bryan Henderson wrote: > >Adding a vfs call to check for file equivalence seems like a good idea to > me. > > That would be only barely useful. It would let 'diff' say, "those are > both the same file," but wouldn't be useful for something trying to > duplicate a filesystem (e.g. a backup program). Such a program can't do > the comparison between every possible pairing of file names. > > I'd rather just see a unique file identifier that's as big as it needs to > be. And the more unique the better. (There are lots of degrees of > uniqueness; unique as long as the files exist; as long as the filesystems > are mounted, etc.). the other option which wouldn't work with file system as they exist today would be for a system call that would say "give inode X, give me all name links to this inode". Essentially a reverse database of sorts As I said, wouldn't work with today's file systems, but would help stackable file systems, as they have no way of knowing about hard links, at least if not created through them (and in that case they would have to implement the above mentioned reverse database).