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

[Greg Chicares]

Vadim--Does this make any sense to you?

Kim's trying to upgrade to MinGW-w64 gcc-7.2 on an msw-7 cygwin
machine, where we use native binaries distributed by the MinGW-w64
project (not the cygwin-dependent binaries offered in the cygwin
installer). After adjusting /etc/fstab manually (correctly, but
that's centrally relevant here), running 'install_msw.sh' yielded:

cd /cache_for_lmi/downloads && echo "f34ff6eca4aa7a645f60c977b107c5d2 
*i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z" | md5sum --check
i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z: OK

[That clearly succeeded.]

bsdtar --extract --keep-old-files --directory=scratch 
--file=/cache_for_lmi/downloads/i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z \
  || c:/Program\ Files/7-Zip/7z x `cygpath -w 
/cache_for_lmi/downloads/i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z` -oscratch

[That succeeded, too. We verified that by manually pasting just
the first line (everything up to but excluding the '\') into a
shell, and observing that a 'scratch/mingw32' subdirectory was
created, containing a large number of files. Okay so far.]

mv scratch/mingw32 /MinGW_
mv: cannot move 'scratch/mingw32' to '/MinGW_': Permission denied
make: *** [install_mingw.make:104: all] Error 1

This surprised me. And we were able to reproduce it manually.

Above, we verified that 'scratch/mingw32' exists, and seems to
contain the expected files.

Might msw "security" software prevent writing to '/MinGW_", e.g.,
because it looks like it's in the root directory? No, for two
reasons. First of all, it's not the msw root: it'd be the cygwin
root, i.e., something like "C:\cygwin-lmi\". Second, it's not
actually even the cygwin root, because /etc/fstab contains:
  C:/opt/lmi/MinGW-7_2_0 /MinGW_ lmi_specific binary,user 0 0
so it's really a mount point into /opt/lmi, where we certainly
have full access rights. There's no conflicting older mount
left over from a gcc-6.3 installation: we simply replaced
s/6_3_0/7_2_0/ and verified our work carefully.

Maybe the problem is bad permissions? No, running 'ls -l' in
each of those subdirectories' parents shows that we own them.

Is 'mv.exe' blocked as a matter of "security"? No, the same log
shows nearly-identical 'mv' commands succeeding in similar
circumstances.

Can the directories be on different msw "volumes", in which
case 'mv' would use copy rather than move semantics? No,
that's not imaginable for two subdirectories of /opt/lmi/ in
a cygwin root.

This 'mv' command being all that stood between us and success,
we tried brute force:
  cp -a scratch/mingw32 /MinGW_
and that worked. How can 'cp' succeed where 'mv' failed?

My only guess is that this rather terse diagnostic:
  mv: cannot move 'scratch/mingw32' to '/MinGW_': Permission denied
is telling us that scratch/mingw32 contains some read-only
files. And, indeed, I repeated all the steps carefully on my
GNU/Linux machine, and observed:

$ls -lR scratch |grep '^-r--' |head -5
-r--r--r-- 1 greg greg   1189 Oct 18 21:20 fakepq.h
-r--r--r-- 1 greg greg   6347 Oct 18 21:20 fakesql.h
-r--r--r-- 1 greg greg   4982 Oct 18 21:20 odbcStubs.h
-r--r--r-- 1 greg greg   3584 Oct 18 21:20 pqStubs.h
-r--r--r--  1 greg greg  2430300 Oct 18 21:32 libcrypto.dll.a

In GNU/Linux, the original 'mv' command worked. In cygwin, it
didn't. My hypothesis is that cygwin can't mv a directory that
contains read-only files, due to some underlying rule of the
msw system call it uses. Is that even plausible?