Duplicated and corrupted directories

[jackburton]

Since a few revisions, I'm getting duplicated and truncated folder names. Screenshot attached.

[axeld]

When build under Linux, I would guess? We recently switched to a new bfs_shell, so I would expect the problem to be there.

[jackburton]

Replying to axeld:

When build under Linux, I would guess?

Yes, sorry, I should have specified.

[korli]

Did you use the -j option for jam ?

[jackburton]

Replying to korli:

Did you use the -j option for jam ?

No. I also tried to do a full rebuild (jam -qa haiku.image) but the problem persists.

[bonefish]

Mmh, "since a few revisions" doesn't quite sound like since r20975 (almost 3 weeks ago). Or do you think, I could have been since then?

Since everything works fine here, it would be nice, if you could test a few things. One would be to create an empty image (just insert an "exit 0" in build/scripts/build_haiku_image before the image is mounted (second bfs_shell invocation)), run the bfs_shell interactively ("jam -q run ':<build>bfs_shell' :haiku.image") and try to create a few directories.

The other thing would be to add a bit of output in src/tools/fs_shell/fssh.cpp:command_mkdir() (print to stderr).

Since I'm clueless what code be the source of the problem, ATM, we'll have to see what those tests turn up and probably investigate a little further.

[jackburton]

Replying to bonefish:

Mmh, "since a few revisions" doesn't quite sound like since r20975 (almost 3 weeks ago). Or do you think, I could have been since then?

I would think it started after that, (actually I thought it could've been r21200, but if fixing a memory leak breaks BFS this much...) but I can't be sure because I didn't test any image carefully enough since r20975 or also before that.

Since everything works fine here, it would be nice, if you could test a few things. One would be to create an empty image (just insert an "exit 0" in build/scripts/build_haiku_image before the image is mounted (second bfs_shell invocation)), run the bfs_shell interactively ("jam -q run ':<build>bfs_shell' :haiku.image") and try to create a few directories. The other thing would be to add a bit of output in src/tools/fs_shell/fssh.cpp:command_mkdir() (print to stderr). Since I'm clueless what code be the source of the problem, ATM, we'll have to see what those tests turn up and probably investigate a little further.

I'll try to do those tests later or tomorrow. BTW I've just downlaoded the image built from r21224 at HaikuHost (  http://haikuhost.com/housestrain/ ) and it suffers from the same problem.

[bonefish]

My source tree was few days old (r21173). After updating it I can reproduce the problem, too. Will investigate further ...

[bonefish]

I verified, that the produced image is indeed not OK. Mounting it under BeOS works, but listing e.g. home directory results in "No such file or directory" messages for the entries. Mounting and listing with the bfs_shell under Linux works fine, though; no duplicate/broken directories to be seen. As checked via debug output, when populating the image, bfs_create_dir() is invoked only once per directory, with the correct name.

Using binary search, I tracked the first revision for which the image is broken down to r21194 (Stefano, can you verify this please). I fail to see, how the change would be related, though. It affects only Haiku kernel and libroot. The bfs_shell should not even be rebuilt. I wouldn't rule out an indirect effect due to a size change of files copied to the image, which might trigger a BFS bug, but at least the sizes of kernel and libroot.so remain the same (didn't check stuff linked against them).

Ideas what could be the reason or how to track the problem down are most welcome.

[jackburton]

Replying to bonefish:

Using binary search, I tracked the first revision for which the image is broken down to r21194 (Stefano, can you verify this please).

Correct. r21194 is indeed the first revision which shows this bug.

[axeld]

I think there is a pretty simple explanation for this: I must have broken find_directory() with those changes, causing it to create the wrong entries. I'll look into it.

[axeld]

Fixed in r21239. Sorry, bonefish for letting you find my bugs again - at least next time I'll investigate first before you'll get my victim again :-)