Hi, Fr�d�ric! > Hi. I can reproduce it using the following: > > $ cd /home/pervalidus/tmp > $ mkdir objdir (or F7) > $ cd objdir > $ lndir /usr/src/linux-2.4.17 (after make mrproper)
You only forgot to mention that /home/pervalidus/tmp is on tmpfs. I could reproduce the bug. I also reduced it to a simpler test. This script creates an "undeletable" directory on tmpfs: ================== cut here ================== #!/bin/sh while test -e dir; do rm -rf dir done mkdir dir i=0 while test $i != 168; do touch dir/$i i=$(($i+1)) done mkdir dir/dir2 ================== cut here ================== If less than 168 files are created then the bug cannot be reproduced. If dir/dir2 is created before the files, then the bug cannot be reproduced either! Running mc in the debugger shows that readdir() loses some entries after removing directories. Removing every subdirectory causes lossage of one entry 168 entries later. "Later" means "created earlier" - tmpfs seems to work as LIFO (last in, first out). The problem can be reproduced under Linux-2.4.18-pre1. I'll try to fix it in the kernel. Whether I succeed or not, I'll report it to the kernel mailing list. I guess that "rm -f" just tries harder. It's possible to add this behavior to MC. For example, the loop for the directory could be restarted whenever a subdirectory is removed or whenever the directory cannot be removed because it's not empty. However, it may be hard to avoid reporting the same error to the user, something that "rm -rf" doesn't have to worry about. Anyway, I don't think that MC should work around filesystem bugs. They may be very dangerous and should be detected and fixed as soon as possible. Thank you for reporting the problem! -- Regards, Pavel Roskin _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
