Re: [PATCH] mv: report missing destination leading directory

From: Lucas Zamboni Orioli <lucaszam0@gmail.com>
Date: Jul 22, 2026, 21:32 UTC
Message-ID: <CAH01Q-9vWb0j3=W=vZ4yrAvaofabeZH2hYR8m_haviqZnp6DHg@mail.gmail.com>
In-Reply-To: <C6C7AB29-7027-467B-8DCC-3443CC356628@gmail.com>

Em qua., 15 de jul. de 2026 às 13:50, Ben Knoble <ben.knoble@gmail.com> escreveu:

> I suppose this still allows a TOCTOU issue where the check succeeds and (with lucky timing) the destination then disappears?

Thank you for the feedback, also great catch, this does end up with a TOCTOU issue.

>
> In that case, I think a worthwhile additional change would also be for the error message to diagnose which file is missing (or at least include both source and destination).
>
> Now, without checking I somehow doubt whether rename(2) tells us which entry is missing. Worse, if we check afterwards, we could have a « TOUTOC » :p where the entry reappears to confuse the error diagnosis.

I think your suggestion of including both source and destination in the error message is a good solution, I verified rename(2) just in case and it does not provide the information about which file is missing.

So what I'm thinking of doing is change the error message to

        fatal: renaming 'source/file' to 'destination/file' failed: No
        such file or directory

'%s' to '%s' seems to be more in the pattern of other git messages instead of the cp arrow style.

So for v2 I'll split this into two commits:

        1. mv: name both source and destination when rename fails
                (the die_errno change is race-free and always applicable)
        2. mv: check for missing destination directory before renaming
                (the checking-phase/dry-run detection)

The first stands on its own even if the second is dropped, so I'll order it first.

Since this introduces a new message I'll leave the po/ files to the l10n team, the new message adds one string and the early check reuses the existing 'destination directory does not exist' one.