Re: [lmi] Cannot 'mv' read-only files on cygwin?

[Greg Chicares]

On 2018-03-06 00:39, Vadim Zeitlin wrote:
> On Mon, 5 Mar 2018 23:37:17 +0000 Greg Chicares <address@hidden> wrote:
[...]
> [... snip the problem description ...]
> 
> GC> In GNU/Linux, the original 'mv' command worked. In cygwin, it
> GC> didn't. My hypothesis is that cygwin can't mv a directory that
> GC> contains read-only files, due to some underlying rule of the
> GC> msw system call it uses. Is that even plausible?
> 
>  I don't think so. At least I've never heard about anything like this and I
> can't reproduce it.

Yesterday, I thought that hypothesis might explain this anomaly for
MinGW-w64, whose gcc-7.2.0 tarball really does contain read-only files.
But it happened again today, with both wxWidgets and wxPdfDoc, and I
don't see read-only files in their tarballs, so it seems that the
hypothesis is completed discredited.

>  OTOH there is a very common problem that can prevent a directory from
> being moved, which is that it's used as the current working directory for
> some process and I strongly suspect that this might have happened here.
> It's difficult to check it now that the directory was moved, but if it
> happens again, could you please use the indispensable Process Explorer tool
> (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer)
> and do a search for the directory name in it? It would show you all
> processes using the given directory, just like lsof(1) would under Unix.

Perhaps, but I don't really see how that could happen. The directory
we were trying to move contained a compiler that we wouldn't have
thought of using in its original location, which was a subdirectory
of a just-created scratch directory. So I favor this alternative:

>  The only other thing I can think of is that some file(s) under this
> directory were locked by antivirus software, which is plausible as it's
> supposed to scan any new files, such as these ones. However in this case,
> moving the directory should have succeeded after some time, when the virus
> scan would have finished, so if you tried, and failed, to move it again
> after a sufficiently long time has passed, it would seem to rule out this
> explanation.

Whatever the ultimate cause may have been, I've changed the makefiles
to use 'cp -a'...'rm -rf' instead of 'mv', and everything worked:
Kim successfully built lmi with gcc-7.2.0 . After a few days of
testing, we hope we'll be able to make this our "official" compiler.
When that happens, I'll attack the backlog of patches, which might
become simpler if we can just use C++17 everywhere.