public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx•de>
To: Johannes Sixt <j6t@kdbg•org>
Cc: Karsten Blees via GitGitGadget <gitgitgadget@gmail•com>,
	 git@vger•kernel.org
Subject: Re: [PATCH 11/18] mingw: support renaming symlinks
Date: Fri, 9 Jan 2026 21:04:40 +0100 (CET)	[thread overview]
Message-ID: <99570ae3-d34d-c917-e218-ebbf3f9d7b6c@gmx.de> (raw)
In-Reply-To: <02fa15af-5a57-4557-b016-fd14b9107c6e@kdbg.org>

Hi Hannes,

On Thu, 18 Dec 2025, Johannes Sixt wrote:

> Am 17.12.25 um 15:08 schrieb Karsten Blees via GitGitGadget:
> > From: Karsten Blees <blees@dcon•de>
> > 
> > Older MSVCRT's `_wrename()` function cannot rename symlinks over
> > existing files: it returns success without doing anything. Newer
> > MSVCR*.dll versions probably do not share this problem: according to CRT
> > sources, they just call `MoveFileEx()` with the `MOVEFILE_COPY_ALLOWED`
> > flag.
> > 
> > Avoid the `_wrename()` call, and go with directly calling
> > `MoveFileEx()`, with proper error handling of course.
> > 
> > Signed-off-by: Karsten Blees <blees@dcon•de>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx•de>
> > ---
> >  compat/mingw.c | 38 ++++++++++++++++----------------------
> >  1 file changed, 16 insertions(+), 22 deletions(-)
> > 
> > diff --git a/compat/mingw.c b/compat/mingw.c
> > index b1cc30d0f1..55f0bb478e 100644
> > --- a/compat/mingw.c
> > +++ b/compat/mingw.c
> > @@ -2275,7 +2275,7 @@ int mingw_accept(int sockfd1, struct sockaddr *sa, socklen_t *sz)
> >  int mingw_rename(const char *pold, const char *pnew)
> >  {
> >  	static int supports_file_rename_info_ex = 1;
> > -	DWORD attrs, gle;
> > +	DWORD attrs = INVALID_FILE_ATTRIBUTES, gle;
> >  	int tries = 0;
> >  	wchar_t wpold[MAX_PATH], wpnew[MAX_PATH];
> >  	int wpnew_len;
> > @@ -2286,15 +2286,6 @@ int mingw_rename(const char *pold, const char *pnew)
> >  	if (wpnew_len < 0)
> >  		return -1;
> >  
> > -	/*
> > -	 * Try native rename() first to get errno right.
> > -	 * It is based on MoveFile(), which cannot overwrite existing files.
> > -	 */
> > -	if (!_wrename(wpold, wpnew))
> > -		return 0;
> > -	if (errno != EEXIST)
> > -		return -1;
> > -
> >  repeat:
> >  	if (supports_file_rename_info_ex) {
> >  		/*
> > @@ -2370,13 +2361,22 @@ repeat:
> >  		 * to retry.
> >  		 */
> >  	} else {
> > -		if (MoveFileExW(wpold, wpnew, MOVEFILE_REPLACE_EXISTING))
> > +		if (MoveFileExW(wpold, wpnew,
> > +				MOVEFILE_REPLACE_EXISTING | MOVEFILE_COPY_ALLOWED))
> >  			return 0;
> >  		gle = GetLastError();
> >  	}
> >  
> > -	/* TODO: translate more errors */
> > -	if (gle == ERROR_ACCESS_DENIED &&
> > +	/* revert file attributes on failure */
> > +	if (attrs != INVALID_FILE_ATTRIBUTES)
> > +		SetFileAttributesW(wpnew, attrs);
> > +
> > +	if (!is_file_in_use_error(gle)) {
> > +		errno = err_win_to_posix(gle);
> > +		return -1;
> > +	}
> > +
> > +	if (attrs == INVALID_FILE_ATTRIBUTES &&
> >  	    (attrs = GetFileAttributesW(wpnew)) != INVALID_FILE_ATTRIBUTES) {
> >  		if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
> >  			DWORD attrsold = GetFileAttributesW(wpold);
> > @@ -2388,16 +2388,10 @@ repeat:
> >  			return -1;
> >  		}
> >  		if ((attrs & FILE_ATTRIBUTE_READONLY) &&
> > -		    SetFileAttributesW(wpnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
> > -			if (MoveFileExW(wpold, wpnew, MOVEFILE_REPLACE_EXISTING))
> > -				return 0;
> > -			gle = GetLastError();
> > -			/* revert file attributes on failure */
> > -			SetFileAttributesW(wpnew, attrs);
> > -		}
> > +		    SetFileAttributesW(wpnew, attrs & ~FILE_ATTRIBUTE_READONLY))
> > +			goto repeat;
> >  	}
> > -	if (gle == ERROR_ACCESS_DENIED &&
> > -	       retry_ask_yes_no(&tries, "Rename from '%s' to '%s' failed. "
> > +	if (retry_ask_yes_no(&tries, "Rename from '%s' to '%s' failed. "
> >  		       "Should I try again?", pold, pnew))
> >  		goto repeat;
> >  
> 
> The logic in this function is incredibly convoluted. It does look
> somewhat reasonable, at least on the non-error path, but whether the
> variable attr is changed and reset as needed after 'goto repeat' and the
> various failure modes, I cannot tell. I give up and trust that this code
> has been battle-tested during the past decade and works as desired.

I do agree that the logic is quite convoluted. Historically grown, like.
But as you suspect: This has been battle-hardened, and I am loathe to
introduce a regression by making it prettier at this point. This is tried
and tested code, and that counts for something.

Ciao,
Johannes


  reply	other threads:[~2026-01-09 20:04 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-17 14:08 [PATCH 00/18] Support symbolic links on Windows Johannes Schindelin via GitGitGadget
2025-12-17 14:08 ` [PATCH 01/18] mingw: don't call `GetFileAttributes()` twice in `mingw_lstat()` Karsten Blees via GitGitGadget
2025-12-18 10:34   ` Johannes Sixt
2025-12-17 14:08 ` [PATCH 02/18] mingw: implement `stat()` with symlink support Karsten Blees via GitGitGadget
2025-12-18 10:44   ` Johannes Sixt
2026-01-09 20:04     ` Johannes Schindelin
2025-12-17 14:08 ` [PATCH 03/18] mingw: drop the separate `do_lstat()` function Karsten Blees via GitGitGadget
2025-12-18 10:48   ` Johannes Sixt
2025-12-17 14:08 ` [PATCH 04/18] mingw: let `mingw_lstat()` error early upon problems with reparse points Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 05/18] mingw: teach dirent about symlinks Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 06/18] mingw: compute the correct size for symlinks in `mingw_lstat()` Bill Zissimopoulos via GitGitGadget
2025-12-17 14:08 ` [PATCH 07/18] mingw: factor out the retry logic Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 08/18] mingw: change default of `core.symlinks` to false Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 09/18] mingw: add symlink-specific error codes Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 10/18] mingw: handle symlinks to directories in `mingw_unlink()` Karsten Blees via GitGitGadget
2025-12-18  2:49   ` Ben Knoble
2026-01-09 20:04     ` Johannes Schindelin
2025-12-17 14:08 ` [PATCH 11/18] mingw: support renaming symlinks Karsten Blees via GitGitGadget
2025-12-18 17:44   ` Johannes Sixt
2026-01-09 20:04     ` Johannes Schindelin [this message]
2025-12-17 14:08 ` [PATCH 12/18] mingw: allow `mingw_chdir()` to change to symlink-resolved directories Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 13/18] mingw: implement `readlink()` Karsten Blees via GitGitGadget
2025-12-18 18:13   ` Johannes Sixt
2026-01-09 20:04     ` Johannes Schindelin
2025-12-17 14:08 ` [PATCH 14/18] mingw: implement basic `symlink()` functionality (file symlinks only) Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 15/18] mingw: add support for symlinks to directories Karsten Blees via GitGitGadget
2025-12-17 14:08 ` [PATCH 16/18] mingw: try to create symlinks without elevated permissions Johannes Schindelin via GitGitGadget
2025-12-17 14:08 ` [PATCH 17/18] mingw: emulate `stat()` a little more faithfully Johannes Schindelin via GitGitGadget
2025-12-17 14:08 ` [PATCH 18/18] mingw: special-case index entries for symlinks with buggy size Johannes Schindelin via GitGitGadget
2025-12-18  0:00 ` [PATCH 00/18] Support symbolic links on Windows Junio C Hamano
2025-12-18 18:51 ` Johannes Sixt
2025-12-18 19:33   ` Karsten Blees
2026-01-09 20:04 ` [PATCH v2 " Johannes Schindelin via GitGitGadget
2026-01-09 20:04   ` [PATCH v2 01/18] mingw: don't call `GetFileAttributes()` twice in `mingw_lstat()` Karsten Blees via GitGitGadget
2026-01-09 20:04   ` [PATCH v2 02/18] mingw: implement `stat()` with symlink support Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 03/18] mingw: drop the separate `do_lstat()` function Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 04/18] mingw: let `mingw_lstat()` error early upon problems with reparse points Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 05/18] mingw: teach dirent about symlinks Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 06/18] mingw: compute the correct size for symlinks in `mingw_lstat()` Bill Zissimopoulos via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 07/18] mingw: factor out the retry logic Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 08/18] mingw: change default of `core.symlinks` to false Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 09/18] mingw: add symlink-specific error codes Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 10/18] mingw: handle symlinks to directories in `mingw_unlink()` Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 11/18] mingw: support renaming symlinks Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 12/18] mingw: allow `mingw_chdir()` to change to symlink-resolved directories Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 13/18] mingw: implement `readlink()` Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 14/18] mingw: implement basic `symlink()` functionality (file symlinks only) Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 15/18] mingw: add support for symlinks to directories Karsten Blees via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 16/18] mingw: try to create symlinks without elevated permissions Johannes Schindelin via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 17/18] mingw: emulate `stat()` a little more faithfully Johannes Schindelin via GitGitGadget
2026-01-09 20:05   ` [PATCH v2 18/18] mingw: special-case index entries for symlinks with buggy size Johannes Schindelin via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99570ae3-d34d-c917-e218-ebbf3f9d7b6c@gmx.de \
    --to=johannes.schindelin@gmx$(echo .)de \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitgitgadget@gmail$(echo .)com \
    --cc=j6t@kdbg$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox