On Feb 22, 2:19 am, unix_fan <tmell...@web.dewrote:
What is the best way to poll a directory for the arrival of files?
The OpenGroup
(http://www.opengroup.org/onlinepubs/...h/readdir.html)
says:
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.
This would seem to identify rewinddir() as a reliable
synchronization point - a place where the system re-scans the directory on
the disk.
That is /your/ assumption, that the "system re-scans the directory on
disk".
Too bad your assumption is false-to-the-facts.
But rewinddir() doesn't return any error messages!
That would imply that no disk I/O is necessary.
Yes? So? Why would rewinddir() return any sort of error under these
circumstances? And why would (or should) it perform any sort of I/O?
rewinddir() simply resets it's position in the directory "stream" to
before the first entry That's all that is necessary to satisfy the
requirement, as the subsequent readdir() call will perform the actual
I/O and read the first dirent from the directory.
This seems to me to be a specification bug. Is that correct?
Not likely. More likely a bug in your understanding of what
rewinddir() does in order to accomplish the requirements of the
specification.
A related question - what is the cost of an opendir()? If rewinddir()
really does check in with the disk, then what is the cost difference
between opendir() and rewinddir()?
opendir() will perform a directory open, rewinddir() will not. Beyond
that, there is no "cost difference" as opendir() and rewinddir() does
the same thing: position to before the first directory entry, clear
all buffers, and prepare for the first readdir() call.
Maybe I'll just use closedir()/opendir() to be safe (but that seems
unfortunate).
Thats overkill for your misunderstanding of what opendir()/readdir()/
rewinddir()/closedir() do.
HTH
--
Lew