[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  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  ---
Author: fxcoudert
Date: Sun Aug 16 12:47:15 2015
New Revision: 226923

URL: https://gcc.gnu.org/viewcvs?rev=226923=gcc=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  ---
Documentation added.

[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|-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.

[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