Hi Vyacheslav and Sergei, I was hoping not to feed into the issues. I believe the bottom line is that, there are a few interesting and challenging issues with HFS+ support, and there are simply not enough people who are both knowledgeable and motivated to improve on it. So we should try to work together. Does it sound reasonable? Sergei: - I appreciate that you are the first to point out the endian issue with the journal, and been working on other aspects, such as the foldercount issue. I would be happy to see more work from you, and continue to be willing to have a look and review, where time permits. However, I do see a few problems with the manner in which you approach this work. From my personal point of view (and I cannot speak for others), file system work is data-safety first. So while Vyacheslav's work might be on the verbose side, it is re-assuring to read, maybe repeatedly, about the details, than skipping on boring details. I don't think length of code should be a criteria, and certainly not "elegance", or cleverness. Here is a widely quoted saying from Brian Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Also, if you deviate from how HFS+ works either at the specification level, the behavior level or the code level, you are just implementing your own journalling work. I would also have preferred that you point out exactly where Vyacheslav's work went wrong, and supply a patch on top, instead of starting your own. If you want credit for it, I hope you can arrange with Vyacheslav to swap the order of signed-off, for one or more of the merged patches, for example. In any case, while I am happy to see your work, and am willing to review it, you have not convinced me to try your work out yet. So. Vyacheslav: Thanks for the continuous good work. While your adherence to TN1150 is good, I have noticed a few times that you have not paid attention to Apple's implementation of it - xnu's kernel code and diskdev_cmds (apple's mkfs/fsck). It is apparent in some of the discussion between you and Sergei that he has read some of those but you haven't. This is shown in the discussion about meaning and naming of variables, and interpretation of reserved fields. About TN1150, I think there is one instance about journalling support (a block count?) where it is ambiguous and contradicctory about a +1 offset. Anyway, I think reference to the actual implementations are welcomed in resolving these ambiguities and clarifying issues. To the both of you, looking forward, and a few technical issues: - I think fsck.hfsplus must manipulate the journal - fs with a non-empty journal is by definition unclean; but fsck may or may not be doing journal replay. It probably does something else, like just zero'ing the journal and fixes inconsistency in the rest. At some point we should find out what fsck does when it fixes an unclean fs with non-empty journal. - 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. - on the many-year-old issue of the driver getting confused just running "du" recursing down large directories, I have managed to make it happen under Ftrace the Linux kernel internal tracer, and even with code mod's, but the resulting log is too large and events are being dropped. So I need to do some filtering to get events down to a fully-recordable level. I.e. it would help to confirm issues if I know where to look... 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
