POSIX Mistake: rewinddir returns no errors!

[unix_fan]

What is the best way to poll a directory for the arrival of files?

The OpenGroup
(http://www.opengroup.org/onlinepubs/007908799/xsh/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.

But rewinddir() doesn't return any error messages!

That would imply that no disk I/O is necessary.

This seems to me to be a specification bug. Is that correct?

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()?

Maybe I'll just use closedir()/opendir() to be safe (but that seems
unfortunate).

 

[santosh]

What is the best way to poll a directory for the arrival of files?

The subject of this group is standard C which has no builtin concept
of "directories" and no portable way to monitor them. Please try
comp.unix.programmer or comp.programming.

 

[Flash Gordon]

unix_fan wrote, On 22/02/07 07:19:

What is the best way to poll a directory for the arrival of files?

<snip>

Using a POSIX specific method. You cannot do it in standard C which is
the topic of this group, fortunately for you there is
comp.unix.programmer for dealing with programming problems that are
specific to Unix.

 

[Lew Pitcher]

What is the best way to poll a directory for the arrival of files?

The OpenGroup
(http://www.opengroup.org/onlinepubs/007908799/xsh/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

 

[Marco van de Voort]

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.

But rewinddir() doesn't return any error messages!

Possible workaround (From the FreeBSD man page):

Since rewind() does not return a value, an application wishing to detect
errors should clear errno, then call rewind(), and if errno is
non-zero, assume an error has occurred.

That would imply that no disk I/O is necessary.
This seems to me to be a specification bug. Is that correct?

The manpage seems to indicate yes.

A related question - what is the cost of an opendir()?

Hard to say. Buffering implementations (most nowadays) might read up a
buffer full of DIRs ahead to save on syscalls on later readdirs. Some might
do it only on the first readdir.

 

[Keith Thompson]

Possible workaround (From the FreeBSD man page):

Since rewind() does not return a value, an application wishing to detect
errors should clear errno, then call rewind(), and if errno is
non-zero, assume an error has occurred.

Of course rewind() and rewinddir() are two different functions. The
advice for rewind() might also apply to the non-standard rewinddir().

But it's not very good advice for rewind(). The standard says:

The rewind function sets the file position indicator for the
stream pointed to by stream to the beginning of the file. It is
equivalent to

(void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.

So if you want to do the equivalent of rewind() but with error
checking, just use fseek() instead.

There may not be an equivalent solution for rewinddir(). For more
information, try comp.unix.programmer -- where this entire discussion
should probably be.

[...]

 

[CBFalconer]

.... snip ...


Thats overkill for your misunderstanding of what
opendir()/readdir()/rewinddir()/closedir() do.

There is no opendir/readir/rewinddir/closedir in the C language.
This is off-topic, and should not be in this news-group.

 

[Barry Margolin]

What is the best way to poll a directory for the arrival of files?

The OpenGroup
(http://www.opengroup.org/onlinepubs/007908799/xsh/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.

No it doesn't, it just has to reset its pointer to the beginning of the
directory. The above paragraph simply says that the system isn't
required to make a snapshot of the entire directory or lock the
directory -- if a change is made, you might or might not see it, and it
probably depends on how much buffering readdir() does.

But rewinddir() doesn't return any error messages!

That would imply that no disk I/O is necessary.

Right, it's just resetting a pointer. It's analogous to lseek(fd, 0,
SEEK_SET).

This seems to me to be a specification bug. Is that correct?

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() has to find the special file and verify that it's a directory.
Rewinddir() doesn't have to do any of this.

Maybe I'll just use closedir()/opendir() to be safe (but that seems
unfortunate).

The only benefit of that is if the the directory is renamed or deleted
and another directory given the original name. You'll get the new
directory instead of continuing to scan the old one.