From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: PROBLEM: hfsplus filesystem allows opendir() on plain files Date: Sat, 6 Dec 2008 22:35:04 +0000 Message-ID: <20081206223504.GT28946@ZenIV.linux.org.uk> References: <493553C0.2090407@frey.co.nz> <20081202222111.GA2738@cynthia.pants.nu> <20081205093948.GA15714@infradead.org> <20081206063226.GB13807@cynthia.pants.nu> <20081206064739.GN28946@ZenIV.linux.org.uk> <20081206072122.GC13807@cynthia.pants.nu> <20081206223133.GR28946@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Damian Stewart , linux-fsdevel@vger.kernel.org To: Brad Boyer Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58052 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752938AbYLFWfI (ORCPT ); Sat, 6 Dec 2008 17:35:08 -0500 Content-Disposition: inline In-Reply-To: <20081206223133.GR28946@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Dec 06, 2008 at 10:31:33PM +0000, Al Viro wrote: > On Fri, Dec 05, 2008 at 11:21:22PM -0800, Brad Boyer wrote: > > > Apple added hard links with osx. Back when I wrote hfsplus originally, > > there wasn't any such thing on HFS+ either. The support for the hack > > that added the appearance of hard links was added after I stopped > > maintaining the code. It's really just a matter of hiding the real > > file in a special place and putting stubs with special settings where > > all the links appear in the namespace. In all truth both HFS and HFS+ > > are inherently incompatible with the very concept of a hard link or > > having a file still exist after removal. It's just a horrible hack > > that makes it look like it works. > > Well... That's not too unreasonably way to do them, actually - just > treat your hidden directory as real inode table. The tricky part is > keeping i_ino stable through all that, but if it's done... > > FWIW, fs/qnx4 uses a somewhat similar scheme, IIRC. > > To make things workable you need > * hidden directory that would never be reachable by syscalls > * recognizable files that would contain references to names > in that directory > * lookup that would normally lead to such file getting inode > of object in hidden directory > * link(2) with target being *not* one of those would start with > moving target to hidden directory and creating such "link" file in its > place. Then it would create a link file in source. That, BTW, would have > interesting implications wrt locking - we'd need to modify target's parent, > which can get sucky. > * unlink(2) with victim dentry not being a "link" file *and* being > busy would move the victim to hidden. Otherwise it'd kill the victim > outright. > * final iput() of file that'd been taken to hidden does deletion > of directory entry in hidden if i_nlink is 0. > > The interesting part is locking - you need to deal with lookup vs. eviction > of link(2) target to hidden and with rename vs. the same thing. PS: that's for handling link(2) on non-directories with that kind of layout, *NOT* for file-cross-directory hybrids or links to directories.