]> git.ipfire.org Git - thirdparty/git.git/commit
mingw: compute the correct size for symlinks in `mingw_lstat()`
authorBill Zissimopoulos <billziss@navimatics.com>
Fri, 9 Jan 2026 20:05:03 +0000 (20:05 +0000)
committerJunio C Hamano <gitster@pobox.com>
Sat, 10 Jan 2026 02:32:55 +0000 (18:32 -0800)
commit543a91ccf9ba551eb563abb44eef0deadf3e38b7
tree18f1ad2b2863bd4b82c8b59c235bc43db7c63ab6
parent8a4f4131aad8d2b176f83df628ee3a8d6e19ba6c
mingw: compute the correct size for symlinks in `mingw_lstat()`

POSIX specifies that upon successful return from `lstat()`: "the
value of the st_size member shall be set to the length of the pathname
contained in the symbolic link not including any terminating null byte".

Git typically doesn't trust the `stat.st_size` member of symlinks (e.g.
see `strbuf_readlink()`). Therefore, it is tempting to save on the extra
overhead of opening and reading the reparse point merely to calculate
the exact size of the link target.

This is, in fact, what Git for Windows did, from May 2015 to May 2020.
At least almost: some functions take shortcuts if `st_size` is 0 (e.g.
`diff_populate_filespec()`), hence Git for Windows hard-coded the length
of all symlinks to MAX_PATH.

This did cause problems, though, specifically in Git repositories
that were also accessed by Git for Cygwin or Git for WSL. For example,
doing `git reset --hard` using Git for Windows would update the size of
symlinks in the index to be MAX_PATH; at a later time Git for Cygwin
or Git for WSL would find that symlinks have changed size during `git
status` and update the index. And then Git for Windows would think that
the index needs to be updated. Even if the symlinks did not, in fact,
change. To avoid that, the correct size must be determined.

Signed-off-by: Bill Zissimopoulos <billziss@navimatics.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/mingw.c