From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustav Munkby Subject: Re: [PATCH] hfsplus: disable rename of directory hardlinks Date: Tue, 03 May 2011 23:29:38 +0200 Message-ID: <4DC073C2.2040609@gmail.com> References: <4DC00D13.5060903@gmail.com> <1304432773-6212-1-git-send-email-grddev@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Al Viro , "linux-fsdevel@vger.kernel.org" To: Andreas Dilger Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:34786 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755289Ab1ECVaS (ORCPT ); Tue, 3 May 2011 17:30:18 -0400 Received: by eyx24 with SMTP id 24so165200eyx.19 for ; Tue, 03 May 2011 14:30:17 -0700 (PDT) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: >> + /* Renaming directory hardlinks to could create loops. >> + * Conservatively prevent any hardlink renaming. >> + */ > > It should also be safe to rename a directory hard link if the source and target parent directories are the same. > > This would allow the case of changing the directory name without moving it to another location. Theoretically, yes. In fact, it seems the implementation on OS X is even more liberal by alos allowing moves into other directories as long as the target is not already beneath another hardlink. However, for that to make sense, proper support for renaming hardlinks (files as well as directories) must first be implemented. The way I understand the hfsplus code both rename and unlink is currently broken for any type of hardlink, because it operates on the link target rather than the link source. Hardlinks in HFS+ are represented much like low-level soft links, with one target file/directory in a private system directory, and several link sources. Operating on the link target would invalidate all link sources on rename/unlink, which is clearly not desired.