Re: mc + tmpfs bug ?

[Pavel Roskin <proski gnu org>]

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