[m-dev.] EISDIR and file opening

[Paul Bone]

I noticed recently that, at least on my Linux system, opening with fopen() a
directory will succeed. Errors will be returned when you attempt to read
from the returned file object.

Should the library code check that it has not just opened a directory within
the open code? Rather than waiting for the caller to attempt to read from
the file?

Thanks.

[Peter Wang]

Post by Paul Bone
I noticed recently that, at least on my Linux system, opening with fopen() a
directory will succeed. Errors will be returned when you attempt to read
from the returned file object.
Should the library code check that it has not just opened a directory within
the open code? Rather than waiting for the caller to attempt to read from
the file?

Hi Paul,

For what it's worth, FreeBSD still allows read() on directories.
I'm having trouble seeing the utility, though. In general, I would
veer towards not imposing additional restrictions on top of the OS,
but Mercury streams are their own abstraction.

An argument against the directory check is that it adds an additional
system call (I assume) for every file opened, when most applications
should be able to handle the EISDIR like any other error.

Peter

[Paul Bone]

Post by Peter Wang

Post by Paul Bone
I noticed recently that, at least on my Linux system, opening with fopen() a
directory will succeed. Errors will be returned when you attempt to read
from the returned file object.
Should the library code check that it has not just opened a directory within
the open code? Rather than waiting for the caller to attempt to read from
the file?

Hi Paul,
For what it's worth, FreeBSD still allows read() on directories.
I'm having trouble seeing the utility, though. In general, I would
veer towards not imposing additional restrictions on top of the OS,
but Mercury streams are their own abstraction.

That FreeBSD could lead to even more confusing behaviour makes me want to
change this even more.

Post by Peter Wang
An argument against the directory check is that it adds an additional
system call (I assume) for every file opened, when most applications
should be able to handle the EISDIR like any other error.

Assuming that it makes another syscall we could reduce this impact by only
doing this on FreeBSD systems, and possibly also Linux systems (if an open
error is better than a read error).

[Julien Fischer]

Hi Paul,

Post by Paul Bone
I noticed recently that, at least on my Linux system, opening with fopen() a
directory will succeed. Errors will be returned when you attempt to read
from the returned file object.
Should the library code check that it has not just opened a directory within
the open code? Rather than waiting for the caller to attempt to read from
the file?

All three non-C backends perform the check when an attempt to open file
is made and return an error if it is a directory. For consistency, this
should also be the (documented) behaviour of the C backends.

Julien.