Re: [PATCH 13/18] mingw: implement `readlink()`

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 9, 2026, 20:04 UTC
Message-ID: <5fe64b77-d10b-b66e-8622-14bec1e96f4a@gmx.de>
In-Reply-To: <8826825b-79ad-4700-aeb5-71e7847ca5dc@kdbg.org>

Hi Hannes,

On Thu, 18 Dec 2025, Johannes Sixt wrote:

Show 10 quoted lines

> Am 17.12.25 um 15:08 schrieb Karsten Blees via GitGitGadget:
> > From: Karsten Blees <blees@dcon.de>
> > 
> > Implement `readlink()` by reading NTFS reparse points via the
> > `read_reparse_point()` function that was introduced earlier to determine
> > the length of symlink targets. Works for symlinks and directory
> > junctions. If symlinks are disabled, fail with `ENOSYS`.
> 
> This last sentence is obsolete, I think, because I cannot see how the
> patch achieves a failure with ENOSYS.

Indeed, this is obsolete. Just like with the ELOOP commit message comment of 02/18, I must have dropped this because reading symlinks should work even if creating symlinks has been disabled via `core.symlinks`. Here is the range-diff between the last version of the patch that still had the ENOSYS logic and the first version that lacked it (Git for Windows-only commits):

1:  4f353d988de4 ! 1:  1d079621427c Win32: implement readlink()

   @@ compat/mingw.c: int link(const char *oldpath, const char *newpath)
    +	char tmpbuf[MAX_LONG_PATH];
    +	int len;
    +
   -+	/* fail if symlinks are disabled */
   -+	if (!has_symlinks) {
   -+		errno = ENOSYS;
   -+		return -1;
   -+	}
   -+
    +	if (xutftowcs_long_path(wpath, path) < 0)
    +		return -1;
    +

So: Unfortunately I have no record that I can readily produce that would
motivate that change. Given that it happened during the same v2.19.2
timeframe as the ELOOP change, there must have been some broader
discussion about this, but I could not find it, not even in the release
notes of that version:
https://github.com/git-for-windows/git/releases/tag/v2.19.2.windows.1

All I can present is the reconstructed rationale that just because Git is not allowed (or able) to create symlinks does not mean that they cannot exist, and therefore Git should at least read and parse them as expected, independent of the value of `core.symlinks`.

So yes, this part of the commit message is just simply confusing at this point, so I'll drop it.

Ciao, Johannes