Hi Vyacheslav,

--- On Wed, 25/7/12, Vyacheslav Dubeyko <slava@dubeyko.com> wrote:

Hi Hin-Tak,

Sorry, I can see from the hfsplus code about what you are
talking. You
are right. The situation is clear for me. It needs to work.
:-)

Thank you for bug report.

With the best regards,
Vyacheslav Dubeyko.

I was going to confess that I might be using buggy code - it is rather a long history, but I am testing a port of netgear's HFS+ journalling change to current kernel. The long and short of the story is that Netgear contracted some company to add HFS+ support in 2010, which they released as a NAS product in 2011, and therefore posted a tar ball of modified 2.6.15 kernel source. This was worked on to port to 3.0-ish last summer, and I am moving it forward to 3.4.x-ish. Updating the journal shouldn't cause the kind of things I saw  - even if it is done wrongly, I was hoping. 

I am using 3.4.5/3.4.6, and indeed on special code branch and on journalled hfs+. It is an MBR disk.

I found that I can cause massive amount of problem by just untarring some big thing and then deleting the files one by one. (I did this with the netgear tar ball, which contains a kernel tree, and after comparing against a git checkout of the relevant version, delete identical files one by one from a list with a script).

i.e. try something similar to this:
  tar -jxpvf kernel-tarball.tar.bz2 > somewhere_else/file-list
  cat somewhere_else/file-list | perl -ne 'chomp; if (-f $_) {unlink $_;}'

On a separate but related note,

- there are 6 netgear tarballs, with 2 implementations of hfs+ journalling.  i.e. there is a slightly newer hfs+ journalling from them since we checked last summer. The newer code copied the whole of /jbd/ from ext3 and renamed everything from jbd to hfsplus_jbd, etc and added some small HFS+-related things. Rather ugly, but possibly do something similiar as jbd does for ext3.

- there is a commercial/free-for-personal-use implementation of hfs+ support from a company Paragon, released last summer, for 2.6.38-. Doesn't build with current kernel; it is almost like nvidia/ATI's X 3D drivers - small glue code to build a kernel module against a binary-only archive library. (also Paragon's HFS+ product for windows seems to make a lot of mac users unhappy for corrupting data, but I might be doing some selective reading there :-))

- I have been looking at some random HFS+ disk images I have as well. One - the command line tools from xcode on apple's web site - is interesting in that the HFS+ volume header says it is over 400MB, but the file itself is only 180MB so obviously there is no secondary volume header (which is located at the end of volume). Or at least, not at the expected location. But Mac OS X does not have problem mounting it - there is only about 180MB worth of stuff inside.

I am thinking maybe for disk images, and also read-only mount, one should not need to check the secondary volume header, as this seems to be what Mac OS X is doing.

The interesting disk image is one of the command-line-tools from xcode on apple's web site (free registration). A few of them are compressed, which is at about 150MB, but one is 180MB, and shows what I wrote about, for those who wants to investigate.

Hin-Tak
 

On Mon, 2012-07-23 at 23:35 +0400, Vyacheslav Dubeyko
wrote:

quoted

Hi,

On Jul 22, 2012, at 1:06 AM, Hin-Tak Leung wrote:

quoted

Correct - two interesting bugs. I thought I had

supplied enough details for others to try to reproduce? The
first is simply about deleting files, the latter about
deleting files with extended attributes. So, to reproduce:

quoted

quoted

1. Have a hfs+ volume (created under Mac OS X

would be better). Make sure it passed fsck.hfsplus (on
linux).

quoted

quoted

2. copy the system Fonts folder (I think it is

under /Library/Fonts) to it from Mac OS X. Font files have
extended attributes, but other system files might do too.

quoted

quoted

3. Try to delete some of those files from Linux.
4. umount, run fsck.hfsplus on the volume. One

would see:

quoted

quoted

  Executing fsck_hfs (version

540.1-Linux).

quoted

quoted

  ...
** Checking extents overflow file.
  Unused node is not erased (node =

1)

quoted

quoted

** Checking catalog file.
  Unused node is not erased (node =

18)

quoted

quoted

  ...
** Checking extended attributes file.
  Incorrect number of extended

attributes

quoted

quoted

  (It should be 13 instead of 6)
  ...
** Repairing volume.
    RepairAttributesCheckABT: No

matching catalog record found for id=438

quoted

quoted

  ...
** Rechecking volume.
  ...
** The volume journalled was repaired

successfully.

quoted

Currently, I can't reproduce these bugs. I think that I

have not fully correct reproduction path. So, I have some
questions.

quoted

What version of Linux kernel do you use? Or maybe do

you have hfsplus file system driver code from special
branch?

quoted

I tried to reproduce these bugs on non-journaled hfs+

volume, firstly, but without success. As I can see you use
journaled hfs+ volume. Maybe the forced mount of journaled
hfs+ was the reason of these bugs? By the way do you use MBR
or GPT partitioned disk?

quoted

quoted

'Unused node is not erased' & 'Incorrect

number of extended attributes' were essentially what I wrote
earlier. BTW, I ran fsck.hfsplus with:

quoted

quoted

fsck.hfsplus -d -D 0x0033 -f 

- i.e. maximum amount of information, and have a

look even if it appears to be clean. (there are -l, -y and
-n switches to control whether fsck.hfsplus would actually
fix anything found or leave it alone and just output info).

quoted

quoted

The font folder is only about a few hundred MB, so

one should be able to experiment with a small pen drive and
do byte-level comparisons to see what fsk.hfsplus is not
happy about and what does it change - although I am sure
looking at diskdev_cmds's source would also be useful. I
just happen to want the font folder for other things I do.

quoted

quoted

--
To unsubscribe from this list: send the line

"unsubscribe linux-fsdevel" in

quoted

quoted

the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

With the best regards,
Vyacheslav Dubeyko.

--
To unsubscribe from this list: send the line

"unsubscribe linux-fsdevel" in

quoted

the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html