Re: reading an empty directory after reboot is very slow
On 2015-04-24 19:41:03 -0500, David Wright wrote:
> Well, that's what I thought, because of the cacheing. But Nicolas
> asked me to try using thousands of files, and so here we are,
> ie, your "new test":
>
> ~ $ for j in `seq 10000` ; do mkdir /tmp/testdir/file$j ; done
> ~ $ ./a.out /tmp/testdir/ > lsout1
> ~ $ ./a.out /tmp/testdir/ > lsout2 ← here I renamed file2621
> ~ $ ./a.out /tmp/testdir/ > lsout3
> ~ $ wc lsout*
> 10003 40009 237834 lsout1
> 10002 40005 237809 lsout2 ← missing entry
> 10003 40009 237890 lsout3
> 30008 120023 713533 total
> ~ $
[...]
> So we have a file gone AWOL because it was renamed during this
> program's execution. (The I numbers here come from dirent;
> there's no call of stat.)
So, I would say that this is a bug. POSIX says in
http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
If a file is removed from or added to the directory after the most
recent call to opendir() or rewinddir(), whether a subsequent call
to readdir() returns an entry for that file is unspecified.
But when a file is renamed, it is nowhere said that the file is
removed from and/or added to the directory. The POSIX spec just
says that the file is "renamed".
[...]
> You said that without "Bob's move", you couldn't miss an entry that
> hasn't been removed.
>
> I've demonstrated that you can.
Because of a *bug*. With a conforming implementation, you can't.
(And if a renamed file were regarded as an entry that was removed,
then this would mean that your example would not be correct, because
this would not be "an entry that hasn't been removed".)
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: