Absolute symlinks with root \ not supported #4586

schletti2000 · 2023-09-04T12:30:55Z

I was not able to find an open or closed issue matching what I'm seeing

Setup

$ git --version --build-options

git version 2.40.1.windows.1
cpu: x86_64
built from commit: ceee26d5cac05a3437097b43d034c4ad2e99d571
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.19045.3208]

Default installation, symlinks on

cat /etc/install-options.txt
Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

Any other interesting things about your environment that might be related
to the issue you're seeing?

** Windows developer mode on, symlink creation policy enabled **

Details

Which terminal/shell are you running Git from?

cmd,git bash

What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.

I am creating an absolute symlink to root (e.g. \opt\v1.0 - /opt/v1.0 in the database). The symlink should work both on windows and linux platforms

git init
echo "*" symlink=dir>.git/info/attributes
MSYS_NO_PATHCONV=1 cmd /c 'mklink /d latest \opt\v1.0 & dir latest?'
git commit -a -m"Test"
git checkout -B develop
MSYS_NO_PATHCONV=1 cmd /c 'rmdir latest && mklink /d latest \opt\v1.1'
git commit -a -m"Update v1.1"
git switch main

When switching back to main, git sees a change from the worktree to the index:

$ git ls-files -s 
120000 095e8e4fe7e9867daddd50592cde400256a4b1cc 0       latest
$ git cat-file blob 095e8e4fe7e9867daddd50592cde400256a4b1cc
/opt/v1.0
$ git diff

diff --git a/latest b/latest
index 095e8e4..81c08f5 120000
--- a/latest
+++ b/latest
@@ -1 +1 @@
-/opt/v1.0
\ No newline at end of file
+C:/opt/v1.0
\ No newline at end of file

However, an absolute symlink only containing \ (or / in the database) does work. So the workaround currently is to create this intermediary symlink root symlink:

04.09.2023  14:17    <SYMLINKD>     latest [root\opt\v1.0]
04.09.2023  14:16    <SYMLINKD>     root [\]

UPDATE: Of course this doesn't work well. The root symlink causes recursion for some processes which are not guarded against loops (see https://unix.stackexchange.com/a/277170/346937)

The root symlink ist left alone by git as [\] (and not updated as [C:\]). mkdir /d can create \opt\v1.0 symlinks without problems (doesnt make sense, but its for cross platform dev and linux can use symlinks like this)

If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?

The text was updated successfully, but these errors were encountered:

dscho · 2023-09-06T07:29:19Z

@schletti2000 Thank you for this exemplary bug report. Thanks to the details, I was able to reproduce, to identify the responsible code and to come up with a patch. PR coming up shortly.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths when we encounter them. However, if the path was a so-called "drive-less" absolute path, i.e. if it was relative to the current drive but did start with a directory separator, we would want even the normalized output to be such a drive-less absolute path. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes git-for-windows#4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes git-for-windows#4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

dscho · 2023-09-07T16:33:13Z

@schletti2000 you can install the latest snapshot to get the fix before the next official Git for Windows release.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…hs intact (#4592) Git for Windows does not handle symbolic links correctly when their target is an absolute path without a drive prefix: a drive prefix is added. These type of paths, however, are completely legitimate on Windows, they are _kind of_ absolute paths, as they are still relative to the current directory's drive. So let's handle them as intended: by ensuring that targets that have no drive prefix _before_ normalization still don't have a drive prefix _after_ normalization. Oddly enough, the code that needs to be patched seems to have nothing to do with symbolic links, but all with long paths. Yet this is precisely the code path taken by `win32_create_symlink()` that adds that drive prefix (via normalization). The reason why only symbolic links seem to be affected is that this is the only usage where the resulting path is persisted instead of merely used in subsequent function calls. This fixes #4586.

schletti2000 · 2023-09-08T12:12:26Z

@schletti2000 you can install the latest snapshot to get the fix before the next official Git for Windows release.

Thank you for the quick fix! I installed the snapshot release and it fixes the problem. I am now able to recover with the standard commands like restore, reset etc. from a broken repository state ( git status show absolute driveless symlink as changed).

Couldn't find the issue mentioned in the shipped release notes but I assume thats because of this being a snapshot build?

dscho · 2023-09-08T12:31:55Z

Couldn't find the issue mentioned in the shipped release notes but I assume thats because of this being a snapshot build?

Hah. More likely because I forgot to mention it ;-) Thank you for pointing this out!

dscho · 2023-09-08T12:33:44Z

/add release note bug Symbolic links whose target is an absolute path without the drive prefix accidentally had a drive prefix added when checked out, rendering them "eternally modified". This bug has been fixed.

The workflow run was started

Symbolic links whose target is an absolute path _without_ the drive prefix [accidentally had a drive prefix added when checked out](git-for-windows/git#4586), rendering them "eternally modified". This bug [has been fixed](git-for-windows/git#4592). Signed-off-by: gitforwindowshelper[bot] <gitforwindowshelper-bot@users.noreply.github.com>

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes git-for-windows#4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When trying to ensure that long paths are handled correctly, we first normalize absolute paths as we encounter them. However, if the path is a so-called "drive-less" absolute path, i.e. if it is relative to the current drive but _does_ start with a directory separator, we would want the normalized path to be such a drive-less absolute path, too. Let's do that, being careful to still include the drive prefix when we need to go through the `\\?\` dance (because there, the drive prefix is absolutely required). This fixes #4586. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho mentioned this issue Sep 6, 2023

When looking at potentially long paths: leave drive-less absolute paths intact #4592

Merged

dscho self-assigned this Sep 6, 2023

dscho added bug git labels Sep 6, 2023

dscho added this to the Next release milestone Sep 6, 2023

dscho closed this as completed in #4592 Sep 7, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Absolute symlinks with root \ not supported #4586

Absolute symlinks with root \ not supported #4586

schletti2000 commented Sep 4, 2023 •

edited

Loading

dscho commented Sep 6, 2023

dscho commented Sep 7, 2023

schletti2000 commented Sep 8, 2023 •

edited

Loading

dscho commented Sep 8, 2023

dscho commented Sep 8, 2023 •

edited by gitforwindowshelper bot

Loading

Absolute symlinks with root \ not supported #4586

Absolute symlinks with root \ not supported #4586

Comments

schletti2000 commented Sep 4, 2023 • edited Loading

Setup

Details

dscho commented Sep 6, 2023

dscho commented Sep 7, 2023

schletti2000 commented Sep 8, 2023 • edited Loading

dscho commented Sep 8, 2023

dscho commented Sep 8, 2023 • edited by gitforwindowshelper bot Loading

schletti2000 commented Sep 4, 2023 •

edited

Loading

schletti2000 commented Sep 8, 2023 •

edited

Loading

dscho commented Sep 8, 2023 •

edited by gitforwindowshelper bot

Loading