Quoting Vincent Lefevre (vinc...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150423162211.GC8639@alum
