Robert Haas <robertmhaas@gmail.com> writes:
> I'd be really interested in knowing whether this happens on a
> mainstream, non-networked filesystem. It's not an irrelevant concern
> even if it happens only on networked filesystems, but a lot more
> people will be at risk if it also happens on ext4 or xfs. It does seem
> a little bit surprising if no filesystem has a way of preventing this.
> I mean, does open() also randomly but with low probability fail to
> find a file that exists, due to a concurrent directory modification on
> some directory in the pathname? I assume that would be unacceptable,
> and the file system has a way of preventing that from happening, then
> it has some way of ensuring a stable read of a directory, at least
> over a short period.
The POSIX spec for readdir(3) has a little bit of info:
The type DIR, which is defined in the <dirent.h> header, represents a
directory stream, which is an ordered sequence of all the directory
entries in a particular directory. Directory entries represent files;
files may be removed from a directory or added to a directory
asynchronously to the operation of readdir().
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.
There is no text suggesting that it's okay to miss, or to double-return,
an entry that is present throughout the scan. So I'd interpret the case
you're worried about as "forbidden by POSIX". Of course, it's known that
NFS fails to provide POSIX semantics in all cases --- but I don't know
if this is one of them.
regards, tom lane