: Subject: Just another vfat bug in 2.1.132/2.2.0pre[12]
:
: Hi,
: It seems to be another fat/vfat bug :
:
: # touch file;mkdir dir;cd dir;mv ../file .
: # cd file
: bash: file: Not a directory
: # cd ..
: # rm -rf dir
: rm: dir: Device or resource busy
:
: [ Why ??? ]
I just lost some sleep worrying about this question.
First of all, the right demo is something like
# mount /dev/foo /mnt -t vfat
# cd /mnt; touch file; mkdir dir; cd dir; mv ../file .
# cd /mnt/dir/file
bash: /mnt/dir/file: Not a directory
# rm file; cd ..; rmdir dir
rmdir: Device or resource busy
(with `right' I mean that it works as a C program;
in fact bash will try both "cd x" and "cd $CWD/x"
when given the command x).
The command "mv ../file ." can also be replaced by
something like "touch ../file2 file" - this is not
a rename bug.
What happens? The "cd /mnt/dir/file" needs the dcache
entry of dir, but the revalidate fails because dir was
timestamped with the version of /mnt, but that changed
when mv ../file . was done. So, the old entry for dir
is dropped and a new lookup is done.
However, the old entry pointed at the same inode as the
new one, so that now i_count=2 and the rmdir fails.
The abovementioned bug is easily reproduced, and still present
in 2.2.0pre4. It is also easy to give patches that make this
particular bug go away, but before doing so I would like to
convince myself that vfat+patches satisfies the obligations.
But what are these precisely (say, for revalidate)?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/