Re: reading an empty directory after reboot is very slow
Quoting Vincent Lefevre (vincent@vinc17.net):
> On 2015-04-23 11:31:27 +0200, Nicolas George wrote:
> > Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> > > David's test shows that the renamed file is missed.
> >
> > No, it shows that the renamed file is NOT missed: he renamed the entry for
> > inode 497003 from file2 into a long name, and that entry is returned,
> > exactly once, under its old name. The "oops, file2 stat() fails" only shows
> > the race condition between readdir() return and stat(); I am sure that if he
> > printed dirent.d_ino instead of stat.st_ino, it would have printed 497003.
Yes, it would. See below as to why I printed the stat() version.
But actually, the answer is no. dirent.d_ino could fail as well.
readdir is not thread-safe so the dirent could get clobbered between
the call to readdir and printing it.
> I only focused on the inode number and I thought that David's test was
> printing dirent.d_ino (which was the obvious thing to do). Now, after
> re-reading carefully what he said:
>
> "I scan the directory with readdir, then stat the file to obtain its
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> inode number."
> ^^^^^^^^^^^^
>
> Indeed, this is the wrong way to do!
Well, the program I filched, because filch it I did, printed more
*interesting* stuff about the file, stuff like the size etc.
I switched it to printing the (to most people, boring) inode number
because, *for the purpose of this exercise*, the inode number acts as
a unique identifier for a file which has just changed name.
I guess if you only even scan directories to admire the interesting
numbers, then leave stat alone and enjoy the delicious delights of dirents!
> So, there's a need for a new test.
Feel free to write it.
Cheers,
David.
Reply to: