MSYS2 installation with a junction in its path

[White-Tiger]

Lets assume I've installed MSYS2 to: C:/Junction/msys64/, where Junction/ points to D:/Stuff/
the execution of pacman -S pacman then fails with

error: cannot remove /usr/bin/pacman.exe (Permission denied)
warning: warning given when extracting /usr/bin/pacman.exe (Could not unlink)

because it wasn't aware of the junction.

Yet if msys64/ itself is a junction, it would actually work as it seems to resolve the junction/symlink in that case. This is also true if you let C:/Junction point to the entire drive D:/ (so you go like C:/Junction/Stuff/msys64)
Also, if you create a junction D:/AnotherJunction/ which points to C:/Junction/msys64/ you can actually see what happens internally:

error: cannot remove /c/Junction/msys64/usr/bin/pacman.exe (Permission denied)
warning: warning given when extracting /c/Junction/msys64/usr/bin/pacman.exe (Could not unlink)

You can see that it resolved the first junction which was the msys64 "root" (D:/AnotherJunction/) but didn't resolve the actual full path.

I've opened this issue following a discussion in #524 as my issue wasn't really related to that one. (just a side note as it annoyed me in the past) So check that other issue for my initial "report" and my there described msys2 update issues.

[elieux]

The Cygwin try_to_bin ("move file away if it can't be deleted right away") function that allows overwriting open files is not smart enough to solve this. I've discussed this with Cygwin maintainers and we have a proposed solution waiting to be implemented. I may try implementing it at some point, but no promises :).

Citing Corinna (hopefully not against her will):

off the top of my head, we might be able to workaround the problem
if we replace the call
status = NtQueryInformationFile (fh, &io, pfni, 65536, FileNameInformation);
with a call to
status = NtQueryObject (h, ObjectNameInformation, poni, 65536, &size);
with typeof(poni) == POBJECT_NAME_INFORMATION
this returns the path as "\Device\HarddiskVolumeX\foo\bar"
this obviously affects some code later on, e. g. the test "pfni->FileNameLength == 2" wouldn't work anymore
the tests definitely gret more complicated
network paths are returned as "\Device\Mup\server\share..."
you get the idea, I guess

[FrankHB]

I have my /etc as junction to another directory (shared with some others). Currently pacman may remove the junction on update, so I need to merge the contents back to make it work. The NT native symbolic link also does not help. Is there any workaround?

[yumetodo]

Are there any updates?

$LC_ALL=C pacman -Syuu
:: Synchronizing package databases...
 mingw32 is up to date
 mingw64 is up to date
 msys is up to date
:: Starting core system upgrade...
 there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (64) bc-1.07.1-2  gawk-5.0.0-1  gdb-8.2.1-1  gdbm-1.18.1-2  gnupg-2.2.15-2  inetutils-1.9.4-2  libgdbm-1.18.1-2  libpcre-8.43-2  libpcre16-8.43-2  libpcre2_16-10.33-2  libpcre2_8-10.33-2
              libpcre32-8.43-2  libpcrecpp-8.43-2  libpcreposix-8.43-2  libreadline-8.0.000-1  libreadline-devel-8.0.000-1  libsqlite-3.27.2-2  libutil-linux-2.33.1-1  libxml2-2.9.9-4
              mingw-w64-i686-boost-1.70.0-2  mingw-w64-i686-cmake-3.14.4-1  mingw-w64-i686-gdb-8.3-2  mingw-w64-i686-gettext-0.19.8.1-8  mingw-w64-i686-glib2-2.60.2-1  mingw-w64-i686-libiconv-1.16-1
              mingw-w64-i686-libuv-1.29.0-1  mingw-w64-i686-openblas-0.3.6-1  mingw-w64-i686-orc-0.4.29-2  mingw-w64-i686-pixman-0.38.4-1  mingw-w64-i686-python2-certifi-2019.3.9-1
              mingw-w64-i686-python2-urllib3-1.25.2-1  mingw-w64-i686-ruby-2.6.3-2  mingw-w64-i686-source-highlight-3.1.8-3  mingw-w64-x86_64-boost-1.70.0-2  mingw-w64-x86_64-cmake-3.14.4-1
              mingw-w64-x86_64-gdb-8.3-2  mingw-w64-x86_64-gettext-0.19.8.1-8  mingw-w64-x86_64-glib2-2.60.2-1  mingw-w64-x86_64-libiconv-1.16-1  mingw-w64-x86_64-libuv-1.29.0-1
              mingw-w64-x86_64-openblas-0.3.6-1  mingw-w64-x86_64-orc-0.4.29-2  mingw-w64-x86_64-pixman-0.38.4-1  mingw-w64-x86_64-python2-certifi-2019.3.9-1  mingw-w64-x86_64-python2-urllib3-1.25.2-1
              mingw-w64-x86_64-python3-certifi-2019.3.9-1  mingw-w64-x86_64-python3-pygments-2.4.0-1  mingw-w64-x86_64-python3-sphinx-2.0.1-1  mingw-w64-x86_64-python3-sphinxcontrib-applehelp-1.0.1-1
              mingw-w64-x86_64-python3-sphinxcontrib-devhelp-1.0.1-1  mingw-w64-x86_64-python3-sphinxcontrib-htmlhelp-1.0.2-1  mingw-w64-x86_64-python3-sphinxcontrib-jsmath-1.0.1-1
              mingw-w64-x86_64-python3-sphinxcontrib-qthelp-1.0.2-1  mingw-w64-x86_64-python3-sphinxcontrib-serializinghtml-1.1.3-1  mingw-w64-x86_64-python3-urllib3-1.25.2-1
              mingw-w64-x86_64-ruby-2.6.3-2  mingw-w64-x86_64-source-highlight-3.1.8-3  mpdecimal-2.4.2-2  pcre-8.43-2  python-3.7.3-1  tftp-hpa-5.2-3  tzcode-2019.a-1  util-linux-2.33.1-1
              vim-8.1.1234-1

Total Installed Size:  1275.54 MiB
Net Upgrade Size:       184.88 MiB

:: Proceed with installation? [Y/n] y
(64/64) checking keys in keyring                                                                                          [#########################################################################] 100%
(64/64) checking package integrity                                                                                        [#########################################################################] 100%
(64/64) loading package files                                                                                             [#########################################################################] 100%
(64/64) checking for file conflicts                                                                                       [#########################################################################] 100%
error: failed to commit transaction (conflicting files)
mingw-w64-x86_64-source-highlight: /mingw64 exists in filesystem
mingw-w64-x86_64-python3-sphinxcontrib-applehelp: /mingw64 exists in filesystem
mingw-w64-x86_64-python3-sphinxcontrib-devhelp: /mingw64 exists in filesystem
mingw-w64-x86_64-python3-sphinxcontrib-htmlhelp: /mingw64 exists in filesystem
mingw-w64-x86_64-python3-sphinxcontrib-jsmath: /mingw64 exists in filesystem
mingw-w64-x86_64-python3-sphinxcontrib-qthelp: /mingw64 exists in filesystem
mingw-w64-x86_64-python3-sphinxcontrib-serializinghtml: /mingw64 exists in filesystem
Errors occurred, no packages were upgraded.

$LC_ALL=C ls -l /
total 640K
-rw-r--r-- 1 yumetodo なし   82 Jul 27  2018 autorebase.bat
-rw-r--r-- 1 yumetodo なし  645 Jul 27  2018 autorebasebase1st.bat
drwxr-xr-x 1 yumetodo なし    0 Apr 28 21:23 bin/
drwxr-xr-x 1 yumetodo なし    0 Dec 23 19:21 clang32/
drwxr-xr-x 1 yumetodo なし    0 Dec 23 19:21 clang64/
drwxr-xr-x 1 yumetodo なし    0 Oct 26  2015 dev/
-rw-r--r-- 1 yumetodo なし  541 Sep 16  2015 dir
drwxr-xr-x 1 yumetodo なし    0 Apr 28 21:23 etc/
drwxr-xr-x 1 yumetodo なし    0 Oct 26  2015 home/
drwxr-xr-x 1 yumetodo なし    0 Apr 28 20:19 lib/
drwxr-xr-x 1 yumetodo なし    0 Apr 28 20:32 mingw32/
-rw-r--r-- 1 yumetodo なし   29 Jun 24  2016 mingw32_shell.bat
lrwxrwxrwx 1 yumetodo なし   16 Apr 29 11:39 mingw64 -> /c/msys2/mingw64/
-rw-r--r-- 1 yumetodo なし   29 Jun 24  2016 mingw64_shell.bat
-rw-r--r-- 1 yumetodo なし  26K Dec 16 03:46 msys2.ico
-rw-r--r-- 1 yumetodo なし 6.1K Dec 16 03:46 msys2_shell.cmd
drwxr-xr-x 1 yumetodo なし    0 Oct 26  2015 opt/
dr-xr-xr-x 8 yumetodo なし    0 May 17 11:35 proc/
drwxr-xr-x 1 yumetodo なし    0 May 17 11:20 tmp/
drwxr-xr-x 1 yumetodo なし    0 Oct 14  2018 usr/
drwxr-xr-x 1 yumetodo なし    0 Oct 26  2015 var/

D:\msys64>dir
 ドライブ D のボリューム ラベルは ボリューム です
 ボリューム シリアル番号は 7650-3C75 です

 D:\msys64 のディレクトリ

2019/04/29  11:39    <DIR>          .
2019/04/29  11:39    <DIR>          ..
2018/07/27  16:59                82 autorebase.bat
2018/07/27  16:59               645 autorebasebase1st.bat
2018/12/23  19:21    <DIR>          clang32
2018/12/23  19:21    <DIR>          clang64
2015/10/26  13:07    <DIR>          dev
2015/09/16  15:34               541 dir
2019/04/28  21:23    <DIR>          etc
2015/10/26  13:07    <DIR>          home
2019/04/28  20:19    <DIR>          lib
2019/04/28  20:32    <DIR>          mingw32
2016/06/24  13:15                29 mingw32_shell.bat
2019/04/29  11:39    <SYMLINKD>     mingw64 [C:\msys2\mingw64]
2016/06/24  13:15                29 mingw64_shell.bat
2018/12/16  03:46            25,758 msys2.ico
2018/12/16  03:46             6,165 msys2_shell.cmd
2015/10/26  13:01    <DIR>          opt
2019/05/17  11:20    <DIR>          tmp
2018/10/14  14:38    <DIR>          usr
2015/10/26  13:07    <DIR>          var
               7 個のファイル              33,249 バイト
              14 個のディレクトリ  206,198,157,312 バイトの空き領域

[mingwandroid]

I don't evil anyone is going to fix this for you. If the people here care about it then fell free to try to investigate. Be prepared to learn more about Cygwin than you wanted to.

Windows supports symbolic links now so there no need to use junction points.

[FrankHB]

@mingwandroid Windows symbolic links do not invalidate the issue. With every installation of Windows I used, they don't work by default, because I am not able to create them without Administrator privileges.

And as I have tried to point out months ago, with a symbolic link to /etc in the installation of msys2, it is definitely problematic. I admit I don't know enough to figure out why even NTFS permissions still do not prevent such a symbolic link is removed, but this seems more specific to msys2 (or pacman in msys2) rather than Cygwin.

(I lose the interest to investigate more in the meantime. I have worked around to just not use them for specific directories like /etc. However, this still is a bug to be fixed.)

[yumetodo]

@mingwandroid Windows native symbolic links that are only permitted to Administrator does not resolve this problem(watch my prev post, dir command shows <SYMLINKD>)

[mingwandroid]

You can use developer mode, I done think that requires admin (once set that is, but I could be wrong).

[FrankHB]

@mingwandroid True, but:

• Sadly, not all installations work with this feature. It needs Win10 build >= 14972. Pre-Win10 systems are still supported by MSYS2, right?
• It still needs someone as Administrator to enable this feature.
• Actually, without developer mode, you can alter the behavior with group policy management editor. This even works in Windows 7. But this also needs Administrator (to define the groups of trusted user accounts) and it does not work with non-elevated Administrators (which seems the main reason to introduce the developer mode with behavior changes of symbolic links creation).
• My problem (not necessarily has the exactly same reason to OP's) still exists after replacing the junction to a symbolic link. At least, with an installation in Win10 1803 (developer mode enabled), no mentioned workarounds will work (except avoiding the links totally).

I hope there can be some fixes, not just workarounds.

[mingwandroid]

I made a bug report and patch for qt some years ago to treat junctions as symlinks.

The bug report gets discussed even now. The current latest statement from Qt is that junctions aren't enough like symlinks for Qt to do this.