Pedro Martelletto wrote:
On Sat, Nov 26, 2005 at 12:57:06AM +0100, Alexander Hall wrote:
$ dd if=/dev/zero of=msdos_fs bs=1024 count=1024
$ sudo vnconfig vnd0 msdos_fs
$ sudo newfs_msdos /dev/rvnd0c
$ sudo mount_msdos -m 777 -l /dev/vnd0c /mnt/test/
$ cd /mnt/test
$ mkdir a aa ab
$ find .
.
./a
./aa
./ab
Interesting. If you don't do this preliminary 'find', then all is fine.
Yes I noticed that, too. :)
$ mv aa ab a
If I do ``mv aa a; mv ab a'', all is fine, too. AFAICT, this should
require the exact same syscalls to perform as ``mv aa ab a''; one for
each file to move. It seems that if things happen too fast things go bad.
Thinking of it, since the first "find" is required to get bad results, I
get the feeling that some caches/vnodes/... are populated with corrupted
values, (but I don't know much about this, so I maybe just better stop
guessing). What I mean is that if so, the error must not be within "rename".
$ find .
.
./a
./a/aa
$ ll a
total 16
drwxrwxrwx 1 root wheel 4096 Nov 26 00:52 aa/
drwxrwxrwx 1 root wheel 4096 Nov 26 00:52 ab/
$ find -L .
.
./a
./a/aa
./a/ab
This one is funny. Don't ask me how come I tested it. Symlinks on
msdosfs? And what are they linking to? :)
And if you try 'rm -rf a' now, you're likely to get:
rm: fts_read: No such file or directory
Actually, after testing copying aa and ab separately, I cannot reproduce
the previous errors again. Maybe a reboot will "help".
FWIW, I think that unmounting and mounting the fs again restored the
order (or so it seemed).
Please let me know if there is anything else I can do to help you.
/Alexander
