[Bug libfortran/41387] New: OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[Bug libfortran/41387] New: OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

The following program:

      OPEN(UNIT=1,FILE='noot',STATUS='NEW')
      END

when compiled/linked into a.out and run as follows:

$ rm aap
$ ln -s aap noot
$ ./a.out

gives:

At line 1 of file a.f (unit = 1, file = '')
Fortran runtime error: File 'noot' already exists

Other compilers (tested: xlf (IBM) and ifort (Intel)) permit to open a
non-existing file as 'NEW' this way.

The reason our run-time library doesn't is that in io/unix.c, we open a 'NEW'
file with open(...., O_CREAT | O_EXCL, ...).

The man page of open says about O_EXCL:

       O_EXCL

Ensure  that  this  call creates the file: if this flag is specified in
conjunction with O_CREAT, and pathname already exists, then open() will fail.
The behavior of O_EXCL is undefined if O_CREAT is not specified.

When these two flags are specified, symbolic links are not followed: if
pathname is a symbolic link, then open() fails regardless of where the
symbolic link points to.


-- 
           Summary: OPEN, STATUS='NEW' of a symbolic link to a non-existing
                    file fails.
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: toon at moene dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

------- Comment #1 from toon at moene dot org  2009-09-17 13:26 -------
Perhaps the system call 'access' can provide help here.

>From the man page (man 2 access):

access() checks whether the calling process can access the file pathname.
If pathname is a symbolic link, it is dereferenced.

The  mode  specifies the accessibility check(s) to be performed, and is either
the value F_OK, or a mask consisting of the bitwise OR of one or more of R_OK,
W_OK, and X_OK.

F_OK tests for the existence of the file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2009-09-17 14:59 -------
This is opening a can of worms.

ln -s aap noot
touch app

program a
  open(unit=10, file='noot', status='old')
  write(10,'(A)') 'Deleted file'
  close(10, status='delete')
end program a

Please audit all Fortran constructs that operate on a
unit= or file=.  You'll also need to audit all of the intrinsic
procedures in libgfortran that operate on a unit= or file=
entity.  When/if an intrinsic procedure is changed to give
consistent behavior on a symlink, please make sure that you
maintain backwards compatibility with g77.

The behavior of a symlink is not specified in any Fortran standard.
This is clearly processor dependent behavior, and should be left
alone.  I'll also note that a symlink does not need to point to
a file to be useful.  See FreeBSD's malloc/free implementation for
an example.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org
           Severity|normal                      |enhancement
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-09-17 19:15 -------
I agree, this is enhancement only.  Code that relies on or expects consistent
behavior when the users has created and symlink is likely not protable.  See

http://gcc.gnu.org/ml/fortran/2009-09/msg00107.html as examples


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

------- Comment #4 from toon at moene dot org  2009-09-17 19:57 -------
In response to reply 2 (thanks Steve), we might be able to exploit the system
call access to at least solve the inconsistency between INQUIRE and OPEN:

man 2 access

       ENOENT A component of pathname does not exist or is a dangling symbolic
              link.

IOW, if we check for this (instead of requesting a stat buffer), we might be
able to answer the question consistently with OPEN.

See libgfortran/io/unix.c:

   1376 /* file_exists()-- Returns nonzero if the current filename exists on
   1377  * the system */
   1378 
   1379 int
   1380 file_exists (const char *file, gfc_charlen_type file_len)
   1381 {
   1382   char path[PATH_MAX + 1];
   1383   struct stat statbuf;
   1384 
   1385   if (unpack_filename (path, file, file_len))
   1386     return 0;
   1387 
   1388   if (stat (path, &statbuf) < 0)
   1389     return 0;
   1390 
   1391   return 1;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2009-09-18 03:52 -------
For additional comments, see

http://gcc.gnu.org/ml/fortran/2009-09/msg00119.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

------- Comment #6 from toon at moene dot org  2009-09-20 17:03 -------
It seems we have exhausted the arguments in this case.

The best cause of action seems to be to document that gfortran won't allow to
open dangling symlinks with STATUS='NEW'.

This bug report remains open until that is done.


-- 

toon at moene dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |toon at moene dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-09-20 17:03:39
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[LpSolit at netscape dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |fxcoudert at gcc dot gnu.org
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Sun Aug 16 12:47:15 2015
New Revision: 226923

URL: https://gcc.gnu.org/viewcvs?rev=226923&root=gcc&view=rev
Log:
        PR fortran/41387
        * gfortran.texi: New section "File operations on symbolic links".

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi

--- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Documentation added.