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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot 
gnu.org

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
OK yes we are not doing anything with the return values of the calls to
'remove'.

The error machinery of generate_error takes care of actually assigning the
values to iostat or iomsg. I suggest the following patch.

diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index cbcbf4e71a1..c5167bcbbc7 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -99,7 +99,11 @@ st_close (st_parameter_close *clp)
              else
                {
 #if HAVE_UNLINK_OPEN_FILE
-                 remove (u->filename);
+
+                 if (remove (u->filename))
+                   generate_error (&clp->common, LIBERROR_OS,
+                           "File can not be deleted, possibly in use by"
+                           " another process");
 #else
                  path = strdup (u->filename);
 #endif
@@ -112,7 +116,10 @@ st_close (st_parameter_close *clp)
 #if !HAVE_UNLINK_OPEN_FILE
       if (path != NULL)
        {
-         remove (path);
+         if (remove (u->filename))
+           generate_error (&clp->common, LIBERROR_OS,
+                   "File can not be deleted, possibly in use by"
+                   " another process");
          free (path);
        }
 #endif

I have not dreamt up a way to test this in a test case. I suppose I could
recreate the virtualbox environment Luke found this in. Reardless we should at
a minimum try to check for an OS error here.  There are many possibilities so I
think the generic LIBERROR_OS we already have is sufficient. (The iostat code
will be 5000)

BTW I have seen where Windows 10 will essentially lock a file under weird
conditions where it thinks a file is being used by some process, including
simply haveing a folder open somewhere where the file resides. Even though this
environment is under Virtualbox under Ubunto, it is ultiately running NTFS and
the access rights in this environment can be obscure.  As an example, I have
mounted NTFS systems using linux and been unable to change the priviliges of
the files.

Luke, do you ever build gcc?

Reply via email to