[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unlink failure on abort

From: Orgad Shaneh
Subject: Re: Unlink failure on abort
Date: Fri, 16 Jun 2017 17:05:58 +0300

On Friday, June 16, 2017, Eli Zaretskii <address@hidden> wrote:
> From: Orgad Shaneh <address@hidden>
> Date: Fri, 16 Jun 2017 15:59:09 +0300
> Cc: address@hidden
>  I don't see any calls to DeleteFile in this log. I expected to see at
>  least one that failed with ERROR_ACCESS_DENIED. What am I missing?
> There is SHARING_VIOLATION for both g++.exe and mingw32-make.exe

Ah, okay.  But then the problem is not with child processes of g++,
it's with g++ itself, right?

The child process cc1plus has the file open for writing, and g++ and make fail to delete it.

And on my system, the file is removed after Make exits, when I use
your recipe.

Do you run mingw make or msys make?
> > Interleaved output is not a problem, it's expected behavior. And it
> > has nothing to do with buffering, since several different instances of
> > make are simultaneously writing to the same device.
> By "interleaved" I mean that in the same line there is "expected" output and interferences. This happens even
> without -j. In the example that I gave in that bug report, it was caused by ^C, which looked like this:
> make: *** Deleting file 'obj/m^ainC.oTerminate batch job (Y/N)? '
> Is this expected?

The "*** Deleting file 'obj/main.o" part is from Make, while the
"Terminate batch job (Y/N)?" part is from cmd.exe.  IOW, two processes
are writing to the same device at the same time.

> With the patch it doesn't happen.

That's what I'd like to understand: how did the MSYS2 maintainers
arrived at the conclusion that the call to setlocale can be related.

CC Alexey. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]