On 2015-04-23 11:22:11 -0500, David Wright wrote: > 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.
This doesn't matter here: the thread-safeness applies to a single process with multiple threads. Here one considers a single-threaded program. Note also that in a multi-threaded program, the full readdir call is concerned by the lack of thread-safeness, not just dirent.d_ino; said otherwise, you mustn't use concurrent readdir in multiple threads (and readdir_r isn't a solution either since it can yield a buffer overflow with arbitrary C libraries). > > 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. Except that you don't show anything special: it is obvious that there is a race condition on the filename when doing a file rename and reading the directory containing that file at the same time, i.e. one can either get the old filename or the new filename. This will be true with *any* filesystem (I mean, the behavior is not specified). > > So, there's a need for a new test. > > Feel free to write it. No need, you have agreed above that the dirent.d_ino is correct (except in case of programming error). -- Vincent Lefèvre <vinc...@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) -- 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/20150424080410.gb6...@xvii.vinc17.org