From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustav Munkby Subject: Re: [PATCH] hfsplus: read support for directory hardlinks Date: Tue, 03 May 2011 16:11:31 +0200 Message-ID: <4DC00D13.5060903@gmail.com> References: <1304072452-6590-1-git-send-email-grddev@gmail.com> <20110502084631.GA14670@lst.de> <20110502124048.GL9487@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:58693 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752852Ab1ECOMM (ORCPT ); Tue, 3 May 2011 10:12:12 -0400 Received: by eyx24 with SMTP id 24so35372eyx.19 for ; Tue, 03 May 2011 07:12:10 -0700 (PDT) In-Reply-To: <20110502124048.GL9487@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. In line with the read-only support, I would suggest to conservatively prevent any rename where the source is a directory hardlink. I have prepared a patch along those lines, but I cannot test it right now.