From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustav Munkby Subject: Re: [PATCH] hfsplus: read support for directory hardlinks Date: Thu, 19 May 2011 17:57:18 +0200 Message-ID: <4DD53DDE.6020605@gmail.com> References: <1304072452-6590-1-git-send-email-grddev@gmail.com> <20110502084631.GA14670@lst.de> <20110502124048.GL9487@ZenIV.linux.org.uk> <4DC00D13.5060903@gmail.com> <20110504093025.GA30023@lst.de> <4DC16AF2.6010000@gmail.com> <20110519110915.GA6506@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Al Viro , linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:33433 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933387Ab1ESP6H (ORCPT ); Thu, 19 May 2011 11:58:07 -0400 Received: by eyx24 with SMTP id 24so844569eyx.19 for ; Thu, 19 May 2011 08:58:06 -0700 (PDT) In-Reply-To: <20110519110915.GA6506@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 05/19/11 13:09, Christoph Hellwig wrote: > Given that our view of how these links behave was a bit too simplistic > I'll drop the patch from my tree for now. I'm actually not quite sure > if we can implement the required locking correctly. It would be > interesting to see what Apple does given that the hfsplus code is > part of the xnu source tarball, but given their general implementaton > quality I'd expect something utterly hacky. I really don't see how the patch makes anything worse. In fact it makes things slightly better by preventing modifications of the files in the hidden directory. The raw files are currently exposed and all renames possible with the patch are equally possible without it. Moreover, I've done some more tests the last few weeks, and it turns out that Apple only implements folder hardlinks for journaled HFS+. Since journaled HFS+ is only supported readonly by the hfsplus driver, the write operations are currently not an issue. It seems the appropriate read-only patch would ensure that the destination folder is always hidden, and folder hardlinks are only ever resolved when the filesystem is mounted read only. This will: - prevent creation of folder hardlinks independent of whether the filesystem is readonly or not; - enable navigation of any folder hardlinks when mounted readonly; - ensure all write operations work well for files not beneath a folder hardlink, including all files on filesystems without folder hardlinks. Thoughts?