Hi, > reiserfsck is supposed to create lost+found if it does not exist. 3.6.18 > has a bug. 3.6.19 is better, but it also has problem with lost+found. Sorry that I didn't look at the differences between 3.6.18 and 3.6.19 in the first place and give 3.6.19 a try. The change_log didn't say anything about lost+found and I assumed that one of the few things went wrong that can go wrong in the function make_sure_lost_found_exists. If you think that this is very unlikely and I only experienced a 3.6.18 bug, I understand that my patch will not be included.
> ftp://ftp.namesys.com/pub/tmp/reiserfsprogs-3.6.19.tar.gz fixes them. (1) I ran diff -r with and without -w and noticed many changes in whitespace, mostly in struct definitions. You may want to fix this before the release of 3.6.20. (2) I looked at the differences of the function make_sure_lost_found_exists (which now moved from semantic_rebuild.c to lost+found.c) and looked into reiserfs_add_entry of the 2.6.13-15.13 SuSE kernel to see what happens if namelen is -1. (Checking for this situation is what has been added since 3.6.18 to make_sure_lost_found_exists.) The first thing that will cause problems is a call to memcpy with count -1. This will overwrite 4 GB of kernel memory on 32-bit i686. Shouldn't that cause a page fault or kill the whole system? Then the bug I experienced most have been a different one because this didn't happen. > successfull reiserfsck is supposed to leave a filesystem in consistent > state [...] Thinking about this a little bit more, reiserfsck is neither supposed to be a full-blown data recovery tools (that would not write to the fs at all) nor a replacement for mkreiserfs + restore of a backup. Its major advantage is that it often brings back a system without any human interaction and at higher speed than the start-from-scratch option (at least if --rebuild-tree is not necessary). Joachim
