On Mar 11, 2016, at 10:34 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > Is it possible that getdents returns a zero inode number for a name > which actually has a file (or directory, device node etc.) behind it? The d_ino == 0 value is valid to return and means that the filename was unlinked from the directory but the entry was not actually removed. I guess if there are files with hard links it is possible that the inode referenced by the unlinked name may still have other paths referencing it, or it is possible if there is a race condition (e.g. getdents() returns a previously deleted name returning d_ino == 0, then a file with the same name being created). POSIX doesn't require that readdir()/getdents() be up-to-date with current file create/unlink state, only when the dirfd was first opened, or if rewinddir() is called: http://pubs.opengroup.org/onlinepubs/009695399/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. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
