From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Antonov Subject: Re: A few thoughts on hfsplus dev (Re: [PATCH v2] hfsplus: add journal replay) Date: Sun, 6 Apr 2014 18:01:04 +0200 Message-ID: References: <1396659774.33612.YahooMailBasic@web172304.mail.ir2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Cc: Vyacheslav Dubeyko , "linux-fsdevel@vger.kernel.org" , Al Viro , Christoph Hellwig , Andrew Morton To: Hin-Tak Leung Return-path: Received: from mail-ob0-f171.google.com ([209.85.214.171]:52368 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753650AbaDFQBG convert rfc822-to-8bit (ORCPT ); Sun, 6 Apr 2014 12:01:06 -0400 Received: by mail-ob0-f171.google.com with SMTP id wn1so5589717obc.16 for ; Sun, 06 Apr 2014 09:01:04 -0700 (PDT) In-Reply-To: <1396659774.33612.YahooMailBasic@web172304.mail.ir2.yahoo.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 5 April 2014 03:02, Hin-Tak Leung wrote: >>> - I have a more re-produce'able recipe of making disk images with strange >>> location of 2nd volume header using hdiutil (Apple's loopback mounting, etc disk image >>> manipulation tool). At some point we should re-visit this issue. >> >>Well, present your recepie. But! There is only one proper placement for this header. All other placements are improper, and the spec even explicitly gives one example of an improper placement. I imagine no ways to get it wrong. I see no need for any elaborate code for finding the 2nd header. >> > > Apple owns the spec, and owns the rights of interpretation and mis-interpretation of it, > and they are not bound by it, and they can freely deviate and change their minds, etc. it > is not an iso spec, it was not submitted to external bodies for standardization - it > is just provided as is. > > You can say Appple's tool is wrong - but a more pragmatic way of seeing it, is that > they don't have to keep the spec up to date or correct; keeping the spec up to date > is going to cost somebody's time to do so; there is no business incentive to > spend the engineering hours to keep the spec up to date. Their tools/implementations > in software is more authoritative than the words in the spec. > > hdiutil is Apple proprietary software. source code is not available. So what is the recipe? I'll make a patch if there really is a bug in the driver.