Hi Sergei, ------------------------------ On Tue, Mar 25, 2014 1:37 AM GMT Sergei Antonov wrote: >Let me inject a remark here. >A reader of my discussion with Vyacheslav here may get an impression that my code cares less about data safety. This impression is false. To make a long story short: replaying+removing transactions one by one is as safe as replaying them all at once and then removing them alltogether. Maybe it is not so for other journal formats, for HFS+ journal it is. > I think a reader of your commit message might get the impression that you are more concerned about performance/elegance/cleverness than correctness. "Doing A is as safe as doing B" - you still have to pick one way or another. Or supply a patch to do both, to demonstrate switching between the two. > >Sigh. You have been misled. That's probably because claims like "you do not follow this excerpt from the spec" are more impressive and easier to remember than my following explanations why I am not. > You are probably assuming that you will always be around to explain to future persons who might want to understand this code; and you are assuming that you are the only person to be working on it? How do you feel about a future person making a commit to revert/correct your work, for example? >> - 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. Hin-Tak -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
