[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #19 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 2 23:21:11 2019 New Revision: 269344 URL: https://gcc.gnu.org/viewcvs?rev=269344=gcc=rev Log: 2019-03-02 Jerry DeLisle PR libfortran/89020 * io/close.c (st_close): Generate error if calls to 'remove' return an error. Modified: branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/io/close.c
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Jerry DeLisle --- Fixed on 8 and trunk, closing.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #18 from Jerry DeLisle --- (In reply to Luke Robison from comment #17) > (In reply to Jerry DeLisle from comment #8) > > > Luke, do you ever build gcc? > > I applied these patches to 8.2.0 and got the expected error message and > iostat of 26. Looks good to me. Thanks. I can backport this so its there sooner, its pretty safe patch.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #17 from Luke Robison --- (In reply to Jerry DeLisle from comment #8) > Luke, do you ever build gcc? I applied these patches to 8.2.0 and got the expected error message and iostat of 26. Looks good to me. Thanks.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #16 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jan 27 19:42:34 2019 New Revision: 268319 URL: https://gcc.gnu.org/viewcvs?rev=268319=gcc=rev Log: 2019-01-27 Jerry DeLisle PR libfortran/89020 * io/close.c (st_close): Simplify text of error message to not presume a specific cause of failure to remove file. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/close.c
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #14 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jan 27 01:36:40 2019 New Revision: 268309 URL: https://gcc.gnu.org/viewcvs?rev=268309=gcc=rev Log: 2019-01-26 Jerry DeLisle PR libfortran/89020 * io/close.c (st_close): Fix typo. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/close.c
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #15 from jvdelisle at charter dot net --- On 1/26/19 1:07 PM, anlauf at gmx dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 > > Harald Anlauf changed: > > What|Removed |Added > > CC||anlauf at gmx dot de > > --- Comment #13 from Harald Anlauf --- > Jerry, > > are you sure that the second part of the patch is intended? > > remove (u->filename) vs. remove (path) > Nope, copy paste, should be 'path'. Will fix. Thanks Jerry
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #13 from Harald Anlauf --- Jerry, are you sure that the second part of the patch is intended? remove (u->filename) vs. remove (path)
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Sat Jan 26 20:27:16 2019 New Revision: 268301 URL: https://gcc.gnu.org/viewcvs?rev=268301=gcc=rev Log: 2019-01-26 Jerry DeLisle PR libfortran/88020 * io/close.c (st_close): Generate error if calls to 'remove' return an error. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/close.c I messed up the changelog, will fix.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #11 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #10) > It seems that the GCC policy is "s/can not/cannot/g". Thanks Dominique, I will fix it. BTW I set up Ubuntu 18 in Virtualbox 6 on Win 10 and it does not have the problem. (Or at least as I set it up, being not too familiar with it.) Luke, you may want to just update your environmnet. Regardless I will commit the changes I proposed as obvious after regression testing. (I would not expect any issue with it.)
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #10 from Dominique d'Humieres --- It seems that the GCC policy is "s/can not/cannot/g".
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
--- Comment #9 from Steve Kargl ---
On Sat, Jan 26, 2019 at 03:49:48AM +, jvdelisle at gcc dot gnu.org wrote:
> --- Comment #8 from Jerry DeLisle ---
> 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 (>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 (>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)
>
Thanks for taking a look at the problem! Learned something new
today with the setting of iostat and iomsg via generate_error.
The patch looks good to me. As for a test, I think that that
might be difficult to dream up. The code already checked if
one has permission to manipulate the file, so creating a file
and using chmod probably won't work. The failure seems to be
a possible race condition from virtualbox's pseudo-filesystem.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
Jerry DeLisle 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 ---
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 (>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 (>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?
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #7 from Steve Kargl --- On Fri, Jan 25, 2019 at 06:40:14PM +, jvdelisle at gcc dot gnu.org wrote: > > --- Comment #6 from Jerry DeLisle --- > (In reply to Steve Kargl from comment #5) > --- snip --- > > > > Of course, I could be missing something obvious. Jerry? > > Hi Steve, I have time today to have a look at this. Does seem a bit unusual on > the surface. > Thanks. I was expecting to see something like result = remove(...) /* returns 0, -1, and set errno. */ if (iostat is present) iostat = result; /* could also set to errno. */ if (iomsg is present) iomsg = strerror (errno); /* Look up errno error message. */
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- (In reply to Steve Kargl from comment #5) --- snip --- > > Of course, I could be missing something obvious. Jerry? Hi Steve, I have time today to have a look at this. Does seem a bit unusual on the surface.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
--- Comment #5 from Steve Kargl ---
On Thu, Jan 24, 2019 at 01:32:56PM +, tkoenig at gcc dot gnu.org wrote:
>
> However, I'd like to look at the code first and check if we
> can actually accommodate this strange behavior without pessimizing
> anything else. If so, I would be inclined to "fix" this.
>
I took a quick peek at the code. I actually could not find
where we set iostat and iomsg if present. For this simple
program
program foo
i = 42
open(unit=7, file='tmp.dat')
write(7,*) 'tmp.dat'
close(7,iostat=i)
print *, i
end program foo
the relevant part of -fdump-tree-original looks like
{
struct __st_parameter_close close_parm.2;
close_parm.2.common.filename = &"t.f90"[1]{lb: 1 sz: 1};
close_parm.2.common.line = 5;
i = 0;
close_parm.2.common.iostat =
close_parm.2.common.flags = 32;
close_parm.2.common.unit = 7;
_gfortran_st_close (_parm.2);
}
So we pass the address of i in the close_parm, but I
don't see libgfortran/io/close.c doing anything with
.iostat (or .iomsg). In fact, st_close() doesn't
check the return status of remove()?
Of course, I could be missing something obvious. Jerry?
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
--- Comment #4 from Luke Robison ---
> First, what virtualbox is doing is a violation of common UNIX
> semantics, so we would be within our rights :-) to do this.
Agreed. This is definitely outside of the norm for a unix
filesystem. I just tried this program on windows native
with mingw-64's gfortran, and the file is deleted as expected.
I don't know enough about mingw-64 to know if they've rewritten
that part of the library, or how they translate those system
calls.
> On the third hand, I seem to remember that unlink / close also
> used to cause (potential?) issues with NFS.
I haven't experienced this yet, although I've been using primarily
lustre network mounts, not NFS.
> Work around for virtualbox might be
> call execute_command_line("rm -f " // filename)
I'm using the (GNU Extension) unlink() function as my work-around.
It isn't strictly Fortran2008, but it is supported by both gfortran
and ifort, so it's good enough for me. (I sure appreciate some of
those highly-compatible extensions, they make my life easier!)
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #3 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #2) > > If virtualbox's shared folders are doing strange things with > > files or is broken, not much that the gfortran developers > > can do about that. > > Hence closing as WONTFIX? First, what virtualbox is doing is a violation of common UNIX semantics, so we would be within our rights :-) to do this. However, I'd like to look at the code first and check if we can actually accommodate this strange behavior without pessimizing anything else. If so, I would be inclined to "fix" this. On the third hand, I seem to remember that unlink / close also used to cause (potential?) issues with NFS.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > If virtualbox's shared folders are doing strange things with > files or is broken, not much that the gfortran developers > can do about that. Hence closing as WONTFIX?
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Luke Robison from comment #0)
> Version: GNU Fortran (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> OS: Guest Ubuntu running inside Host Windows 10 using VirtualBox
>
> Problem:
>
> CLOSE(status='DELETE',iostat=stat) does not delete some files, and still
> returns iostat == 0.
>
> In order to delete files, I use the OPEN(file=..) followed by
> CLOSE(...,status='DELETE') pattern. Normally this works, but
> it fails on VirtualBox's shared folders. Running strace shows
> that the unlink syscall happens while the file is still open,
> and returns ETXTBSY, but the close then proceeds as usual.
> Testing shows that other programs are unable to unlink the
> file while the fortran program has it open either, although
> they can safely unlink it after a CLOSE call.
>
If virtualbox's shared folders are doing strange things with
files or is broken, not much that the gfortran developers
can do about that.
Work around for virtualbox might
call execute_command_line("rm -f " // filename)
