fatal: update_ref failed for ref 'HEAD': cannot update the ref 'HEAD': unable to append to '..../.git/logs/HEAD': Invalid argument

[cheshirecatnyc]

Our network filesystem just switched over from attached storage to CIFS using an equallogic array.
Using most current release 2.27.1 64-bit. Once we switched filesystems, started getting an error with commit and clone.

W:....>git clone https://me@bitbucket.org/myproject/sample.git
Cloning into 'sample'...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 16 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (16/16), done.
error: unable to append to 'W:..../sample/.git/logs/refs/remotes/origin/HEAD': Invalid argument
fatal: update_ref failed for ref 'HEAD': cannot update the ref 'HEAD': unable to append to 'W:.../sample/.git/logs/HEAD': Invalid argument

Same problem with commit.

I can successfully clone/commit from either my local PC c: drive and also from an attached storage network drive.

A colleague is still successfully using 2.17.1.windows.2. I started backtracking - the problem occurs in 2.19.1, but seems to work ok with 2.18.0, so maybe something happened in between those two?

I was looking at this previous issue #1345, and it seems similar, but I don't know the history of this chunk of code and if something changed between 2.18.0 and 2.19.1

Let me know what other info you need.

Setup

git --version --build-options
git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab10
sizeof-long: 4
sizeof-size_t: 8

Windows 10 64-bit

>cmd.exe /c ver

Microsoft Windows [Version 10.0.14393]


>type "C:\Program Files\Git\etc\install-options.txt"
Editor Option: Notepad++
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled

[rimrul]

I was looking at this previous issue #1345, and it seems similar

Yes, that does indeed look quite similar.

, but I don't know the history of this chunk of code and if something changed between 2.18.0 and 2.19.1

2.19.0 introduced mingw_open_append().

Could you try naatje80's test code from that issue?

I've written a small c program to reproduce it:

#include "win32.h"
#include "fcntl.h"
#include <stdio.h>

int main()
{
HANDLE handle;

    DWORD create = (265 & ~O_CREAT) ? OPEN_ALWAYS : OPEN_EXISTING;

    LPCWSTR wfilename = L"./.git/history/test.txt";

   handle = CreateFileW(wfilename, FILE_APPEND_DATA,
                 FILE_SHARE_WRITE | FILE_SHARE_READ,
                 NULL, create, FILE_ATTRIBUTE_NORMAL, NULL);

    //errno = err_win_to_posix(GetLastError()), -1;
    errno = GetLastError(), -1;

    if ( handle == INVALID_HANDLE_VALUE ) {
            printf("ERROR, unable to create file\n");
            printf("Number: %d\n", errno);
    }

}

For this to fail, the directory .git/history should not exists. Normally an error ERROR_PATH_NOT_FOUND (3) should be returned. But when executing on the isilon_storage, a ERROR_INVALID_PARAMETER (87) is returned.

I assume it'll produce some third error (neither ERROR_PATH_NOT_FOUND, nor ERROR_INVALID_PARAMETER, probably one that get's translated to EINVAL in err_win_to_posix()) on the equallogic storage.

[dlevinedclab]

Test code returns this:
ERROR, unable to create file
Number: 3
Seems like in my situation it's failing on append vs create, so maybe we need to try that? Let me know.

[rimrul]

Seems like in my situation it's failing on append vs create, so maybe we need to try that?

We're talking about CreateFileW() with FILE_APPEND_DATA, so create and append should be synonyms for the moment.

Number: 3

So ERROR_PATH_NOT_FOUND. That sounds odd. err_win_to_posix() should translate ERROR_PATH_NOT_FOUND to ENOENT, not EINVAL. ENOENT should be handled in a way that doesn't produce an error containing "unable to append to". ENOENT would also mean that the "Invalid argument" part should be "No such file or directory".

Are you sure you get the same error message?

[dlevinedclab]

Yes, that's the same error message.

For context, this is not critical. We are migrating off our EqualLogic storage in the next few months, and by downgrading back to a prior git version (2.18) or working off local drives we can continue working. But I can continue to help with diagnosis if you want to pursue it.

[rimrul]

Yes, that would be great. You'd probably need to look into debugging git or, if we assume the issue is in mingw_open_append(), we could do some poor mans debugging with something like this:

diff --git a/compat/mingw.c b/compat/mingw.c
index 431ade6e7b..d5783f25dd 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -684,6 +684,8 @@ static int mingw_open_append(wchar_t const *wfilename, int oflags, ...)
 		 */
 		if (err == ERROR_INVALID_PARAMETER)
 			err = ERROR_PATH_NOT_FOUND;
+		else if (err != ERROR_PATH_NOT_FOUND)
+			fprintf(stderr,"ERROR: %d\n", err);
 
 		errno = err_win_to_posix(err);
 		return -1;
-- 
2.27.0.windows.1

[dscho]

+			fprintf(stderr,"ERROR: %d\n", err);

Make that an %ld (since err is of type DWORD, which is an unsigned long I believe).

[dscho]

I guess we can close this now due to lack of interest?

[dlevinedclab]

Yes that’s fine – I haven’t had time to successfully compile git in order to debug, and for my purposes I have a workaround. Thanks for checking in. From: Johannes Schindelin <notifications@github.com> Sent: Tuesday, August 25, 2020 5:41 AM To: git-for-windows/git <git@noreply.github.com> Cc: David Levine <DLevine@dclab.com>; Manual <manual@noreply.github.com> Subject: Re: [git-for-windows/git] fatal: update_ref failed for ref 'HEAD': cannot update the ref 'HEAD': unable to append to '..../.git/logs/HEAD': Invalid argument (#2753) I guess we can close this now due to lack of interest? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#2753 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQLB326W3YDJV4G3DYYBEWDSCOBMRANCNFSM4PCQJO4A>.

[SuperWangKai]

I also meet this issue when using Hyper-V virtual environment. Using old version 2.18 is a workaround. Is there any plan to fix this issue?

[dscho]

Is there any plan to fix this issue?

@SuperWangKai You tell me... As for myself, I am not planning on it, nor am I aware of anybody working on this. So: are you interested enough in seeing this bug fixed to actually go and do the work? I can help, but I cannot do it for you.

[SuperWangKai]

Hi @dscho ,

Thanks for the response.

The issue happens when I clone/pull/commit to a UNC (Universal naming convention) path. In my case, UNC is used for representing host drivers and VM accesses the drivers by the UNC paths. Even pushd is used, the issue still exits.

I'm afraid there is a big gap of knowledge and skills between a normal user and the project developers. However, if no one is going to fix this, I would have a try later.

[dscho]

I'm afraid there is a big gap of knowledge and skills between a normal user and the project developers. However, if no one is going to fix this, I would have a try later.

@SuperWangKai it would go a long way if you provided a short shell script reproducing this (e.g.
using the implicit share, \\C$ if I remember correctly) so that others trying to reproduce do not have to install additional software or set up explicit shares. As a bonus, this can then easily be integrated into Git's test suite, to ensure that no regressions happen.

[sunzhuoshi]

Hi, guys, I've patched to make it work temporarily, but no fully tested right now. Anyone wants to have a try or add tests for it?

[dscho]

Hi, guys,

And gals. Let's not exclude half of humankind in one swift brush of the hand.

I've patched to make it work temporarily, but no fully tested right now. Anyone wants to have a try or add tests for it?

@sunzhuoshi how about tacking a test onto https://github.com/git/git/blob/e9e5ba39a78c8f5057262d49e261b42a8660d5b9/t/t5580-unc-paths.sh#L21-L37, which already uses the "administrative share" \\localhost\c$\... to test things related to UNC paths?

If you need help, it's always a good idea to open a draft PR.

[sunzhuoshi]

@dscho many thanks, a draft PR(#3646) has been done, and CI tests passed.

by the way, I learn "guys and gals" now, I thought "guys" means "everybody"...

[dscho]

I thought "guys" means "everybody"...

Many people think that, usually male people 😁