git clone not works with some ramdisk and ntfs

[yyjdelete]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.15.1.windows.2
built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [版本 10.0.17046.1000]

Also failed with some old stable versions of win10.

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Nano
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Clone into an ramdisk which formated to NTFS.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

bash/cmd

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

1. Install any ramdisk(like https://sourceforge.net/projects/imdisk-toolkit/, or you can install some others).
2. Format the ramdisk to NTFS(FAT32 works well).
3. Just clone anything on the ramdisk.

 git clone <any repository> <any dir on the ramdisk>

• What did you expect to occur after running these commands?

Clone successful.

• What actually happened instead?

Clone failed with the error message below, but the .git folder is created. Both git status and git checkout -f HEAD works.

fatal: This operation must be run in a work tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

** insert URL here **

[yyjdelete]

Seems it's an known issue that some simple ramdisk like imdisk not works with GetFinalPathNameByHandle.(see http://docs.libuv.org/en/v1.x/fs.html, or google GetFinalPathNameByHandle ramdisk)

And found an workaround is to set core.symlinks to false. But if it's ok to add an fallback to use the old value if CreateFileW success and GetFinalPathNameByHandleW failed?

May related to #1007?

[dscho]

Install any ramdisk(like https://sourceforge.net/projects/imdisk-toolkit/, or you can install some others).
Format the ramdisk to NTFS(FAT32 works well).

I would very much appreciate it if you could provide me with a command-line how to call imdisk.exe to set this up. I'd much rather spend my time fixing Git bugs than having to chase down information you already have...

[yyjdelete]

@dscho
Mount(Z:, 128M): imdisk -a -m "Z:" -s 128M -p "/fs:ntfs /q /y"
UnMount: imdisk -D -m "Z:"

[dscho]

@yyjdelete thanks. I did that (did not elevate, so the formatting did not work, but Windows helpfully brought up a dialog whether I want to format the new drive). This is how it looks, though:

Q:\>git clone --depth 1 file:///C:\git-sdk-64\usr\src\build-extra bbb
Cloning into 'bbb'...
remote: Counting objects: 287, done.
remote: Compressing objects: 100% (256/256), done.
Receiving objects: 100% (287/287), 5.97 MiB | 11.13 MiB/s, done.
remote: Total 287 (delta 74), reused 132 (delta 17)
Resolving deltas: 100% (74/74), done.

It also works in Git Bash...

FWIW when I call imdisk --version, the output looks like this:

Control program for the ImDisk Virtual Disk Driver for Windows NT/2000/XP.
Version 2.0.9 - (Compiled Dec 15 2015)

Copyright (C) 2004-2015 Olof Lagerkvist.

http://www.ltr-data.se     [email protected]

<BSD license text, GPL and another reference to a BSD license>

[yyjdelete]

I use the same version of imdisk, not sure what happened.
Can you check whether git config core.symlinks is set to true. This only happened with NTFS and core.symlinks=true.

[dscho]

This only happened with NTFS and core.symlinks=true

That is set automatically when initializing a repository... Git tries to create a symbolic link in .git/ and if it succeeds, it sets that setting to true.

[yyjdelete]

I mean the global/system config(or the one set by setup of GFW), instead of the local config.

[mehrdadn]

@dscho For me, this problem doesn't come up with git clone, only with other operations like git status. Any chance you could revisit this? I've included a full repro below:

To create the RAM drive:

C:\>imdisk -a -s 64M -o rem -m X: -p "/FS:NTFS /Q /S:disable /Y"
Creating device...
Created device 1: X: -> Image in memory
Formatting disk X:...
The type of the file system is RAW.
The new file system is NTFS.
QuickFormatting 64.0 MB
Creating file system structures.
Format complete.
      64.0 MB total disk space.
      61.8 MB are available.
Notifying applications...
Done.

To use it:

C:\>X:

X:\>mkdir Test

X:\>cd Test

X:\Test>git init
Initialized empty Git repository in X:/Test/.git/

X:\Test>git status
fatal: This operation must be run in a work tree

[dscho]

@mehrdadn thank you for the reproducer!

However, it does not reproduce for me...

me@work MINGW64 ~/
$ imdisk -a -s 64M -o rem -m X: -p "/FS:NTFS /Q /S:disable /Y"
The type of the file system is RAW.
The new file system is NTFS.
QuickFormatting 64.0 MB
Creating file system structures.
Format complete.
      64.0 MB total disk space.
      61.8 MB are available.
Creating device...
Created device 0: X: -> Image in memory
Formatting disk X:...
Notifying applications...
Done.

me@work MINGW64 ~/
$ cd /x/

me@work MINGW64 /x
$ mkdir Test

me@work MINGW64 /x
$ cd Test

me@work MINGW64 /x/Test
$ git init
Initialized empty Git repository in X:/Test/.git/

me@work MINGW64 /x/Test (master)
$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Also in CMD:

C:\Users\me>x:

X:\>cd Test

X:\Test>git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

This is with git version 2.16.1.windows.4 for the purpose of this test.

[yyjdelete]

@dscho
Maybe an global or system config core.symlinks=true(can be set by the installer) is needed to reproduce

[mehrdadn]

That's so bizarre. I have core.symlinks=false and it still reproduces. I'm on 2.16.1.windows.1 currently.

[dscho]

@mehrdadn there has been a bug fix that should be unrelated (I am pretty certain it only affects worktrees in a top-level UNC path), but... could you check with the latest snapshot (use the portable installer to avoid messing with your current setup)?

[dscho]

Maybe an global or system config core.symlinks=true(can be set by the installer) is needed to reproduce

@yyjdelete nope, already set:

$ git config core.symlinks
true

[mehrdadn]

Nope it seems the problem is there on the latest snapshot too (as well as .4 etc.).
@dscho, can you reproduce this code failing below? I don't get how it's possibly succeeding (or not getting called) on your system since it uses IOCTL_MOUNTMGR_QUERY_DOS_VOLUME_PATH which fails on ImDisk.

HANDLE folder = CreateFile(TEXT("X:\\Temp"), 0, FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);
TCHAR path[MAX_PATH];
unsigned int const cchpath = sizeof(path) / sizeof(*path);
if (GetFinalPathNameByHandle(folder, path, cchpath, VOLUME_NAME_DOS | FILE_NAME_NORMALIZED))
{ _tprintf(_T("Suceeded: %.*s\n"), static_cast<int>(cchpath), path); }
else
{ _tprintf(_T("Failed: %lu\\n"), GetLastError()); }
CloseHandle(folder);

[dscho]

@mehrdadn fails with:

Failed: 1\n

[mehrdadn]

Yeah that's what's supposed to happen. (Also oops, the backslash. :-) )
That's so strange... so is that function not getting called then...? Hm...

[dscho]

Aaaah!

$ cat /x/Test/.git/config
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true

[mehrdadn]

But mine is false too and I still have this problem?

[dscho]

So what that means is that my system failed to create a symlink on that drive, and set core.symlinks = false. That's why the GetFinalPathByHandle() function is not called in mingw_chdir().

But there is also a GetFinalPathByHandle() function that gets called in mingw_getcwd(). This one is not guarded by has_symlinks, but when GetLongPathNameW() fails... Apparently it succeeds here?

[dscho]

Indeed, I just single-stepped through mingw_getcwd() and it succeeds in calling GetLongPathNameW() on X:\Test, returning the same path. Is that different in your setup @mehrdadn?

[mehrdadn]

Nope it succeeds and returns the same path for me too. I wish I could figure out exactly where GetFinalPathByHandle is called... do you happen to have a build with debug symbols of some sort so that I don't have to rebuild all of git? That way I can put a breakpoint on it and make sure the caller is indeed mingw_getcwd.

[dscho]

I have a debug build, but that is built using GCC... you use Visual Studio, right? You only need the git project (when using the vs/master branch, you have a nice git.sln that you can load), and then you can set up the debugger to run git.exe using the command line options -C X:\Test status.

[mehrdadn]

It seems more painful than that, it seems like I need to also build openssl, iconv, zlib, etc. first before I can do this. If you have symbols for GCC that's fine though, I have MSYS2 installed so I can just run GDB.

[mehrdadn]

Never mind, I finally got it to build. It's very painful though and messed up my environment, so I I'll probably revert it/hope I don't have to do it again :-) here's the stack trace:

git.exe!mingw_chdir(const char * gitdirname=0x000002539dd72510) Line 694	C
git.exe!setup_work_tree() Line 394	C
git.exe!run_builtin(cmd_struct * p=0x00007ff6d7d55d80, int argc=1, const char * * argv=0x000002539dd695f8) Line 344	C
git.exe!handle_builtin(int argc=1, const char * * argv=0x000002539dd695f8) Line 554	C
git.exe!run_argv(int * argcp=0x000000b036affb40, const char * * * argv=0x000000b036affb48) Line 606	C
git.exe!cmd_main(int argc=1, const char * * argv=0x000002539dd695f8) Line 708	C
git.exe!msc_main(int argc=2, const char * * argv=0x000002539dd695f0) Line 44	C
git.exe!msc_startup(int argc=2, wchar_t * * w_argv=0x000002539dd4f910, wchar_t * * w_env=0x000002539dd62630) Line 3428	C
git.exe!wmain(int my_argc=2, wchar_t * * my_w_argv=0x000002539dd4f910, wchar_t * * my_w_env=0x000002539dd62630) Line 26	C

[mehrdadn]

OH... did I never mention I have MSYS=winsymlinks:nativestrict set? Try setting that and you should observe the same behavior as ours!

[dscho]

OH... did I never mention I have MSYS=winsymlinks:nativestrict set? Try setting that and you should observe the same behavior as ours!

Aha! I don't have that set.

[dscho]

/remind me to have a look in two weeks (i.e. after v2.17.0 final)

[reminders]

@dscho set a reminder for Apr 6th 2018

[dscho]

HTH

@MartyIX no, unfortunately it does not. Have you set that MSYS=winsymlinks:nativestrict, too?

[dscho]

I have updated my original post with details about my environment.

Please note that I cannot see such updates from my mail client, therefore I cannot easily comment on those updates. I can only respond easily to new comments.

[dscho]

I spend 15 minutes trying to find where the setting is supposed to be stored and I just don't know..

The MSYS setting is an environment variable. If you do not have that set, can you post a minimal set of commands to reproduce your use case? Like, an ImDisk command-line to create the disk, then possibly a minimal set of Git commands to initialize a worktree that demonstrates your problem.

[mehrdadn]

I'm confused, why is it surprising that the issue is still present in 2.17.0-rc1.windows.1? I didn't think anything changed—was it supposed to have been fixed? Also, I thought the issue is still supposed to occur with core.symlinks set to true, so you seem to be seeing the same behavior as everyone else—not surprising. Or are you asking why core.symlinks is set to true on your system?

[reminders]

👋 @dscho, have a look (i.e. after v2.17.0 final)

[kirillgo]

I have repoduction this problem on Git 2.19.1 (2.19.1.windows.1) on OSFMount ramdisk (2.0 (1001) 64bit for windows 8). OSFMount freeware based on imdisk.
My workstation - Intel Gore i5, 32Gb RAM, Windows 7 Pro SP1 64 bit.

I create simple example example.
This example work on any hard HDD and Dataram RAMDisk V4_4_0_RC36.
But on OSFMount ramdisk work with error:

E:\test_git_symlink>git clone -c core.symlinks=true repo.git repo_b
Cloning into 'repo_b'...
done.
fatal: this operation must be run in a work tree

Reproduction steps Variant 1

1. Dont set MSYS=winsymlinks:nativestrict
2. Download OSFMount - https://www.osforensics.com/tools/mount-disk-images.html
3. Create empty OSFMount ramdisk "osfmount -a -t vm -m "W:" -s 1G"
4. Format disk with NTFS
5. Create test folder test_git_symlink
6. Create bat file create_repo.bat
   create_repo.bat.zip
7. Change first line in create_repo.bat to correct path
8. Execute create_repo.bat on admin rights
9. Last command must create repo_b with content but throw error "fatal: this operation must be run in a work tree"

Reproduction steps Variant 2

1. Set MSYS=winsymlinks:nativestrict
2. Download OSFMount - https://www.osforensics.com/tools/mount-disk-images.html
3. Create empty OSFMount ramdisk "osfmount -a -t vm -m "W:" -s 1G"
4. Format disk with NTFS
5. Change disk to W "cd /D W:"
6. Create test folder repo_a on ramdisk "mkdir repo_a"
7. Step into repo_a "cd repo_a"
8. Init Git repo "git init"
9. Create file "echo "text_a" >file.txt"
10. Add file to repo "git add ."
11. If set MSYS=winsymlinks:nativestrict then last commant throw error "fatal: this operation must be run in a work tree"

[dscho]

Much as I would like, I cannot justify working on this project, as the target audience is such a small fraction of Git for Windows users.

Seeing as nobody else stepped up to the task in over a year, I'll just close this ticket.

[klodoma]

+1 same issue here.

Using imDisk as ramdisk.

Tried the latest snapshot git version 2.30.1.windows.1.4.ga1dbd6927a.20210213012040.

r:\>c:\Portable\Git-ls\bin\git --version
git version 2.30.1.windows.1.4.ga1dbd6927a.20210213012040

r:\>c:\Portable\Git-ls\bin\git clone [email protected]:dumblob/mysql2sqlite.git ms2
Cloning into 'ms2'...
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (9/9), done.
Receiving objects:  76% (105/137)ed 6 (delta 2), pack-reused 126Receiving objects:  74% (102/137)
Receiving objects: 100% (137/137), 43.13 KiB | 532.00 KiB/s, done.
Resolving deltas: 100% (58/58), done.
fatal: this operation must be run in a work tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/

[dscho]

Seeing as nobody else stepped up to the task in over a year, I'll just close this ticket.

@klodoma are you stepping up to the challenge? Assuming that this is what you are talking about, here is some guidance:

1. install Git for Windows' SDK,
2. sdk cd git,
3. git grep "this operation must be run in a work tree" \*.c (over here, it reports builtin/rev-parse.c and setup.c)
4. build Git via make -j$(nproc)
5. debug in-place via GIT_DEBUGGER=1 ./bin-wrappers/git.exe -C /r/ clone [email protected]:dumblob/mysql2sqlite.git ms2
6. this will open the command in gdb. You can now set a break point on setup_work_tree() via b setup_work_tree and then run the command.

Note that I assume that the problem happens somewhere in setup.c, I suspect that chdir_notify() call to fail silently.

If the debugger does not stop in that function but still shows the error message, it can mean one of two things:

1. The error is actually produced by builtin/rev-parse.c
2. The error is produced by a process that is spawned from the process that's being debugged.

If the latter is the case, you might want to instrument the code by inserting a call to open_in_gdb() in the function, then starting the command without GIT_DEBUGGER=1. This should open a new terminal window when that function is called, with a gdb attached to the process. All you need to do in there is to switch to the correct thread (most likely thread 1) and then calling finish until you've stepped out from that open_in_gdb() function (or the SleepEx() it calls).

Please let me know how you fare.

[klodoma]

Seeing as nobody else stepped up to the task in over a year, I'll just close this ticket.

@klodoma are you stepping up to the challenge? Assuming that this is what you are talking about, here is some guidance:

Yes, I'll have a look at it, just to find the time. Thanks for the detailed info, if I need more help, I'll cry out loud.

[mehrdadn]

I took a stab at solving this. I haven't tested it, but (update: just tested it, can someone verify?) I think if you just slip this into mingw.c and link to ntdll.dll, it should work. (It's an alternative for the OS-provided GetFinalPathNameByHandleW.)

typedef enum _OBJECT_INFORMATION_CLASS { ObjectNameInformation = 1 } OBJECT_INFORMATION_CLASS;
typedef struct _UNICODE_STRING { USHORT Length; USHORT MaximumLength; PWSTR Buffer; } UNICODE_STRING, *PUNICODE_STRING;
typedef struct _OBJECT_NAME_INFORMATION { UNICODE_STRING Name; } OBJECT_NAME_INFORMATION, *POBJECT_NAME_INFORMATION;
typedef long NTSTATUS;
// Need to link to ntdll.dll
EXTERN_C NTSYSAPI NTSTATUS NTAPI NtQueryObject(HANDLE Handle, OBJECT_INFORMATION_CLASS ObjectInformationClass, PVOID ObjectInformation, ULONG ObjectInformationLength, PULONG ReturnLength);
EXTERN_C NTSYSAPI ULONG NTAPI RtlNtStatusToDosError(NTSTATUS Status);

DWORD WINAPI GetFinalPathNameByHandleW(HANDLE hFile, LPWSTR lpszFilePath, DWORD cchFilePath, DWORD dwFlags)
{
	DWORD error, result;
	if (dwFlags == 0)
	{
		HANDLE heap = GetProcessHeap();
		ULONG buffer_size = 0;
		buffer_size += sizeof(OBJECT_NAME_INFORMATION);
		buffer_size += MAX_PATH * 3 * sizeof(wchar_t);
		void *buffer = HeapAlloc(heap, 0, buffer_size);
		if (buffer)
		{
			result = 0;
			error = ERROR_PATH_NOT_FOUND;
			for (; ; )
			{
				ULONG required_size = 0, output_size;
				OBJECT_NAME_INFORMATION *const info = (OBJECT_NAME_INFORMATION *)buffer;
				NTSTATUS status = NtQueryObject(hFile, ObjectNameInformation, info, buffer_size, &output_size);
				if (status == 0x80000005 || status == 0xC0000004 || status == 0xC0000023)
				{
					required_size += output_size;
					output_size = 0;
				}
				else if (status != 0) { SetLastError(RtlNtStatusToDosError(status)); break; }
				wchar_t *const volumes = (wchar_t *)((unsigned char *)buffer + output_size);
				DWORD cch = GetLogicalDriveStringsW((buffer_size - output_size) / sizeof(*volumes), volumes);
				if (!cch) { break; }
				required_size += cch * sizeof(*volumes);
				if (status == 0 && 0 < cch && cch <= (buffer_size - output_size) / sizeof(*volumes))
				{
					BOOL found = FALSE, oom = FALSE;
					for (size_t i = 0; i < cch; ++i)
					{
						wchar_t *const name = volumes + i;
						size_t const d = wcsnlen(name, (size_t)cch - i);
						size_t n = d;
						while (n > 0 && name[n - 1] == L'\\') { name[--n] = L'\0'; };
						wchar_t *const path = name + cch + 1;
						size_t m = QueryDosDeviceW(name, path, buffer_size / sizeof(*path) - min(buffer_size / sizeof(*path), output_size + cch + 1));
						if (!m && GetLastError() == ERROR_INSUFFICIENT_BUFFER) { oom = TRUE; break; }
						while (m > 0 && path[m - 1] == L'\0') { --m; }
						if (0 < m && m < info->Name.Length / sizeof(*info->Name.Buffer)
							&& wcsncmp(path, info->Name.Buffer, m) == 0
							&& info->Name.Buffer[m] == L'\\')
						{
							result = (DWORD)(info->Name.Length / sizeof(*info->Name.Buffer) + n - m);
							if (cchFilePath >= result + 1)
							{
								CopyMemory(&lpszFilePath[n], &info->Name.Buffer[m], info->Name.Length - m * sizeof(*info->Name.Buffer));
								CopyMemory(&lpszFilePath[0], name, n * sizeof(*name));
								lpszFilePath[result] = L'\0';
								error = ERROR_SUCCESS;
							}
							else
							{
								++result;
								error = ERROR_BUFFER_OVERFLOW;
							}
							found = TRUE;
							break;
						}
						i += d;
					}
					if (found || !oom)
					{
						break;
					}
				}
				ULONG new_buffer_size = buffer_size + buffer_size / 2 + 1;
				if (new_buffer_size < required_size) { new_buffer_size = required_size; }
				void *const new_buffer = HeapReAlloc(heap, 0, buffer, new_buffer_size);
				if (!new_buffer)
				{
					result = 0;
					error = ERROR_NOT_ENOUGH_MEMORY;
					break;
				}
				buffer = new_buffer;
				buffer_size = new_buffer_size;
			}
			HeapFree(heap, 0, buffer);
		}
		else
		{
			result = 0;
			error = ERROR_NOT_ENOUGH_MEMORY;
		}
	}
	else
	{
		result = 0;
		error = ERROR_CALL_NOT_IMPLEMENTED;
	}
	if (!result && error != ERROR_SUCCESS) { SetLastError(error); }
	return result;
}

@dscho You can take ownership/copyright/etc. of it and edit/merge it in as desired.

[dscho]

You can take ownership/copyright/etc. of it and edit/merge it in as desired.

Actually, I can't. Where I live, authorship cannot be transferred, so there are legal reasons I can't. Also, this change would eventually need to be submitted to upstream Git, which is very clear as to what a "Signed-off-by:" means: the contributor testifies that they are permitted, in a legal sense, to contribute the change. I would not be able to do that for you.

Therefore, I am hopeful that @klodoma will bear the torch from here on out.

Besides, re-implementing GetFinalPathNameByHandleW() seems to be the wrong approach to me. I'd rather react to the specific error returned from that function that describes this scenario, and fall back to what we were doing before we switched to using that function.

[mehrdadn]

Sure, I don't know what it used to be like. To me the easiest & safest route would be to just keep using the original GetFinalPathNameByHandleW and fall back to something else (whether my implementation or a substitute) on error, but anything else that works is obviously fine too.

[dscho]

I could imagine that one of these two commits is the culprit: 4745fee or 41541fe. Neither falls back gracefully if GetFinalPathNameByHandleW() fails, and both of them probably should.

[mehrdadn]

Yeah both would fail here. In general any usage of GetFinalPathNameByHandleW would need to fall back gracefully, so you'd want to just replace it directly (and call the original where possible I guess).

[klodoma]

Just a remark from my side ... I'll have a look at this just to find some time for it.
I am just "under water" with availability these days.

[klodoma]

@dscho you could re-open this ticket... I think it's rolling again :)

[dscho]

I fear that it rolled to a grinding halt.