Issue opening file on NFS read-only mount

[Janne Blomqvist]

On Wed, Nov 13, 2013 at 12:14 PM, N.M. Maclaren <nmm1@cam.ac.uk> wrote:
> On Nov 12 2013, Bob Apodaca wrote:
>>
>>
>> I am still investigating this issue and am not sure which direction to go.
>> Things I have tried:
>> 1. ACTION='READ' and got the same failure.
>
>
> Let's stick with this one, and that is (a component of) the right solution.
>
> If you open a file on a read-only system without that, you should expect
> the open to fail.  A run-time system MAY be kind and retry a read-only
> open, but I have implemented such logic (on a far system and besides the
> machine is dead) and it is foul to get right and unreliable at best; think
> tape files or sockets and weep :-(
>
>
>> If you recall from my previous post, the FORTRAN strace was:
>>
>> stat64("/mnt/nfs/stuff/stuff/more_stuff/file", {st_mode=S_IFREG|0664,
>> st_size=15533, ...}) = 0
>> open("/mnt/nfs/stuff/stuff/more_stuff/file", O_RDWR|O_CREAT|O_LARGEFILE,
>> 0666) = -1 EROFS (Read-only file system)
>> open("/mnt/nfs/stuff/stuff/more_stuff/file", O_RDONLY|O_CREAT|O_LARGEFILE,
>> 0666) = -1 ENOTDIR (Not a directory)
>> write(2, "At line 10 of file file_open.f ("..., 53At line 10 of file
>> file_open.f (unit = 7, file = '')
>> ) = 53
>> write(2, "Fortran runtime error: ", 23Fortran runtime error: ) = 23
>> write(2, "Not a directory", 15Not a directory)         = 15
>> write(2, "\n", 1
>> )                       = 1
>> exit_group(2)                           = ?
>>
>> Could the O_CREAT in the second open() call be causing the problem? Would
>> this be in the gfortran library?
>
>
> Yes and yes.  While POSIX allows O_RDONLY|O_CREAT, it is not a sane
> combination.  A relevant question here is whether the file actually
> existed before the open.
>
> If you use ACTION='READ', do you get just the second call or is is
> different?  Another relevant question here is whether the file actually
> existed before the open.
>
> Aside: unfortunately, Fortran's I/O model is a 1970s insanity that
> never corresponded with any known system and POSIX's is a 1980s
> insanity that never corresponded with any known system, and they are
> wildly different.  What is worse is that neither took appropriate
> account of devices that appear like files (tapes, sockets and worse)
> and so the interpretation of various aspects is at best weird and
> often insane.
>
> I would regard setting O_CREAT in combination with O_RDONLY as a bug,
> not because POSIX forbids it but for that reason.  Unfortunately, it
> may also be done deliberately, again for that reason :-(  Comments in
> the source might say.  It's probably worth opening a bug report - I
> have done a brief search and can find nothing.

Well, if you're curious, the relevant stuff is at

http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/unix.c;h=8a84ae4eef36ac0d235a71d3350d3524807cfd38;hb=HEAD#l1237

In particular, when falling back to trying to open with O_RDONLY after
O_RDWR fails, I think we should mask out O_CREAT as well.

But yeah, a kernel bug report for failing to handle O_RDONLY|O_CREAT
is probably warranted as well.



>
>
> Regards,
> Nick Maclaren.
>



-- 
Janne Blomqvist