On 02/17/2016 09:53 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>
>> Besides shortening the code, this saves an unnecessary call to
>> safe_create_leading_directories_const() in almost all cases.
>>
>> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
>> ---
>> refs/files-backend.c | 76 ++++++++++++++++++++++------------------------------
>> 1 file changed, 32 insertions(+), 44 deletions(-)
>>
>> diff --git a/refs/files-backend.c b/refs/files-backend.c
>> index a549942..e5f964c 100644
>> --- a/refs/files-backend.c
>> +++ b/refs/files-backend.c
>> @@ -2400,55 +2400,43 @@ out:
>> */
>> #define TMP_RENAMED_LOG "logs/refs/.tmp-renamed-log"
>>
>> +static int rename_tmp_log_callback(const char *path, void *cb)
>> +{
>> + int *true_errno = cb;
>> +
>> + if (rename(git_path(TMP_RENAMED_LOG), path)) {
>> + /*
>> + * rename(a, b) when b is an existing directory ought
>> + * to result in ISDIR, but Solaris 5.8 gives ENOTDIR.
>> + * Sheesh. Record the true errno for error reporting,
>> + * but report EISDIR to raceproof_create_file() so
>> + * that it knows to retry.
>> + */
>> + *true_errno = errno;
>> + if (errno==ENOTDIR)
>> + errno = EISDIR;
>
> Style: SP on both sides of a binary operator.
Thanks; will fix.
> More importantly, is ENOTDIR expected only on a buggy platform?
Here I was just mimicking the old behavior, which I think was correct,
but let's check more carefully...
> [ENOTDIR]
> A component of either path prefix names an existing file that is
> neither a directory nor a symbolic link to a directory; or the old
> argument names a directory and the new argument names a
> non-directory file; or the old argument contains at least one non-
> <slash> character and ends with one or more trailing <slash>
> characters and the last pathname component names an existing file
> that is neither a directory nor a symbolic link to a directory; or
> the old argument names an existing non-directory file and the new
> argument names a nonexistent file, contains at least one non-
> <slash> character, and ends with one or more trailing <slash>
> characters; or the new argument names an existing non-directory
> file, contains at least one non- <slash> character, and ends with
> one or more trailing <slash> characters.
>
> i.e. when a leading component of "path" or TMP_RENAMED_LOG is an
> existing non-directory, we could get ENOTDIR on a valid system.
>
> If another instance of Git created a file A/B when this process is
> trying to rename the temporary thing to its final location A/B/C,
> isn't that the errno we would see here?
>
> [EISDIR]
> The new argument points to a directory and the old argument
> points to a file that is not a directory.
>
> Puzzled...
We just created TMP_RENAMED_LOG ourselves, so I don't think we need to
expect errors from that argument. (Though I don't recall that there is
any locking to prevent two `git branch -m` processes from clobbering
each others' temporary files. Oh well; renaming branches is relatively
rare and probably interactive, so I'll declare that potential problem to
be out of scope for this patch series.)
So let's consider the cases where we can get ENOTDIR for `path`:
> A component of either path prefix names an existing file that is
> neither a directory nor a symbolic link to a directory.
This can certainly happen for `path`, but it is not a case that can be
rescued by raceproof_create_file().
> or the old argument names a directory [...]
This is not the case.
> or the old argument contains [...]
Also not interesting.
> or the old argument names an existing non-directory file and the new
> argument names a nonexistent file, contains at least one non-
> <slash> character, and ends with one or more trailing <slash>
> characters
The new argument doesn't end with trailing <slash> characters, so this
can't happen.
> or the new argument names an existing non-directory
> file, contains at least one non- <slash> character, and ends with
> one or more trailing <slash> characters
Ditto.
So while it is true that a non-buggy implementation can give ENOTDIR, it
is for a case that we can't rescue. So if it weren't for the buggy
implementation, we could just leave ENOTDIR un-handled.
Now, we have to consider the opposite case, namely that we are calling a
non-buggy implementation of `rename()`, and we artificially change
ENOTDIR to EISDIR. Can that cause any bad effects?
I don't think so, because the case where a non-buggy implementation can
yield ENOTDIR is a case, the consequent call to
`remove_dir_recursively()` would fail with ENOTDIR too, and
`raceproof_create_file()` would give up immediately.
So I think everything is OK, though I admit that it is not especially
elegant. We could limit ourselves to doing the workaround only on
Solaris 5.8, but that seems like a lot of effort for not much benefit.
Or we could drop the workaround; after all, Solaris 5.8 was released in
2000 and end-of-lifed in 2012. (Though I don't know whether the behavior
was fixed in later versions of Solaris.)
> [...]
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html