When looking at potentially long paths: leave drive-less absolute paths intact #4592
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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>
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 7, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 7, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 7, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 7, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 7, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 7, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 8, 2023
…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.
1 task
github-actions bot
pushed a commit
to git-for-windows/build-extra
that referenced
this pull request
Sep 8, 2023
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>
dscho
added a commit
that referenced
this pull request
Sep 8, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 8, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 8, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 8, 2023
…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
added a commit
that referenced
this pull request
Sep 11, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 11, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 11, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 12, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 13, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 13, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 13, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 13, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 14, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 15, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 15, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Sep 16, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 24, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 24, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 24, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 29, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 30, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 30, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 30, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 30, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 31, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Oct 31, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Nov 1, 2023
…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
added a commit
that referenced
this pull request
Nov 1, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Nov 2, 2023
…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
added a commit
that referenced
this pull request
Nov 2, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Nov 2, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Nov 2, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Nov 2, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Nov 3, 2023
…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
added a commit
that referenced
this pull request
Nov 5, 2023
…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
added a commit
that referenced
this pull request
Nov 13, 2023
…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
added a commit
that referenced
this pull request
Nov 14, 2023
…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
added a commit
that referenced
this pull request
Nov 22, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Dec 2, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Dec 7, 2023
…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
added a commit
that referenced
this pull request
Dec 21, 2023
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Feb 7, 2024
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Feb 8, 2024
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Feb 8, 2024
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Feb 8, 2024
…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.
git-for-windows-ci
pushed a commit
that referenced
this pull request
Feb 8, 2024
…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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.