The described directory operations have traditionally been problematic in terms of portability. A good example is the semantics around ‘.' (dot) and ‘..' (dot-dot). Based on historical implementations, the rules about file descriptors apply to directory streams as well. The IEEE Std 1003.1-2008 (“POSIX.1”) standard does not however any more mandate that directory streams are necessarily implemented by using file descriptors.
The following additional remarks can be noted from the IEEE Std 1003.1-2008 (“POSIX.1”) standard.
•
If the type DIR is implemented using a file descriptor, like in NetBSD, applications should be able to open only OPEN_MAX files and directories. Otherwise the limit is left as unspecified.
•
When a file descriptor is used to implement the directory stream, the closedir() function behaves as if the FD_CLOEXEC had been set for the file descriptor. In another words, it is mandatory that closedir() deallocates the file descriptor.
•
If directory streams are not implemented by using file descriptors, functions such as dirfd() may fail with ENOTSUP.
•
If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), it is unspecified whether a subsequent call to readdir() returns an entry for that file.
•
When using the function seekdir(), note that if the value of loc was not obtained from an earlier call to telldir(), or if a call to rewinddir() occurred between the calls to telldir() and seekdir(), any subsequent call to readdir() is unspecified, possibly resulting undefined behavior.
•
After a call to
fork(2), either the parent or child (but not both) can continue processing the directory stream using
readdir(),
rewinddir(), or
seekdir(). However, if both the parent and child processes use these functions, the result is undefined.