From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH] hfsplus: read support for directory hardlinks Date: Wed, 4 May 2011 11:30:25 +0200 Message-ID: <20110504093025.GA30023@lst.de> References: <1304072452-6590-1-git-send-email-grddev@gmail.com> <20110502084631.GA14670@lst.de> <20110502124048.GL9487@ZenIV.linux.org.uk> <4DC00D13.5060903@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Gustav Munkby Return-path: Received: from verein.lst.de ([213.95.11.211]:51436 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752370Ab1EDJaZ (ORCPT ); Wed, 4 May 2011 05:30:25 -0400 Content-Disposition: inline In-Reply-To: <4DC00D13.5060903@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, May 03, 2011 at 04:11:31PM +0200, Gustav Munkby wrote: > On 05/02/2011 02:40 PM, Al Viro wrote: > > What happens to rename() with that thing? Specifically, what happens to > > loop detection? > > Good point. > > Since my main interest was retrieving contents of a backup, I did not much > consider the impact of write operations. Before the patch, the source files were > exposed as normal files, and the target directories as normal directories, so > one could easily have introduced loops with rename operations before. Given that you have the filesystem around can you clarify where the additional directory links live? I was under the impression they are in hidden backup directories not normally accessible, so there's always just one link in the normal namespace. The basic idea would be that we allow any kind of renames in the normal namespace, but disallow any kind of operation involving the time machine backups.