Re: [PATCH 02/18] mingw: implement `stat()` with symlink support

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 9, 2026, 20:04 UTC
Message-ID: <704e952d-7924-00ce-b8b0-ad355e659335@gmx.de>
In-Reply-To: <46b69027-90b4-439a-a14d-61d1bb739b7b@kdbg.org>

Hi Hannes,

On Thu, 18 Dec 2025, Johannes Sixt wrote:

Show 18 quoted lines

> Am 17.12.25 um 15:08 schrieb Karsten Blees via GitGitGadget:
> > From: Karsten Blees <blees@dcon.de>
> > 
> > With respect to symlinks, the current `mingw_stat()` implementation is
> > almost identical to `mingw_lstat()`: except for the file type (`st_mode
> > & S_IFMT`), it returns information about the link rather than the target.
> > 
> > Implement `mingw_stat()` by opening the file handle requesting minimal
> > permissions, and then calling `GetFileInformationByHandle()` on it. This
> > way, all links are resolved by the Windows file system layer.
> > 
> > If symlinks are disabled, use `mingw_lstat()` as before, but fail with
> > `ELOOP` if a symlink would have to be resolved.
> 
> This last paragraph is disconnected from the patch text. I can't find a
> use of ELOOP anywhere in the code that has something to do with the goal
> of this patch. Is this a remnant from early times where symbolic links
> were optional?

You're right. Sharp eyes, by the way, I cannot count how often I glanced over this paragraph while pre-reviewing.

As to the reason why this paragraph is there: This comes from the initial version of this patch: https://github.com/git-for-windows/git/commit/b908441ea594f022e862c04cefe8ac73bb8c0ab0

I can only try to reconstruct why I skipped the ELOOP logic in the rebased version at https://github.com/git-for-windows/git/commit/0181eb0c78d04f5fb065cbe2f3346077b0f9930e (my guess is that I realized that returning ELOOP when symlink support was disabled via `core.symlinks = false` was undesirable: In particular with Windows 7 semantics, where symlinks could be read and used, but required administrator permissions to create, that flag was meant to turn off symlink _creation_, but reading existing symlinks should work nevertheless).

I'll simply remove this paragraph from the commit message.

Ciao, Johannes