This warning comes from the part of the code that enumerates which files are there, and what their respective status is (tracked, ignored, untracked).

The underlying problem is that the reparse point cannot be resolved due to an infinite recursion. I have this tentative diff locally:

diff --git a/compat/mingw.c b/compat/mingw.c
index cd046da97af..c9843fece4e 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -144,6 +144,7 @@ int err_win_to_posix(DWORD winerr)
 	case ERROR_WAIT_NO_CHILDREN: error = ECHILD; break;
 	case ERROR_WRITE_FAULT: error = EIO; break;
 	case ERROR_WRITE_PROTECT: error = EROFS; break;
+	case ERROR_CANT_RESOLVE_FILENAME: error = ELOOP; break;
 	}
 	return error;
 }

The problem is that strerror(ELOOP) prints out an unhelpful "Unknown error" on Windows:

warning: could not open directory 'a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/': Unknown error

I am not quite sure how best to proceed from here. Currently, my favorite solution would involve introducing platform-specific platform_strerror(int errno) that can override/extend strerror(). While it is my favorite solution, I still find it very inelegant.

BTW the problem has very little to do with the git clean command itself: even a git status triggers the error.

The problem is that strerror(ELOOP) prints out an unhelpful "Unknown error" on Windows:

warning: could not open directory 'a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/b/a/': Unknown error

I am not quite sure how best to proceed from here. Currently, my favorite solution would involve introducing platform-specific platform_strerror(int errno) that can override/extend strerror(). While it is my favorite solution, I still find it very inelegant.

Honestly, the whole concept of mappping GetLastError() to errno is inelegant in the fact it loses precision. I'm pretty sure FormatMessage() wouldn't produce "Unknown Error" or "Function not implemented" for ERROR_CANT_RESOLVE_FILENAME.

Honestly, the whole concept of mappping GetLastError() to errno is inelegant in the fact it loses precision.

Agreed.

Introducing an abstraction layer that does not assume that everything has a POSIX errno is not going to be a small project, though:

$ git grep 'errno = ' | wc -l
257

I have a similar issue when using pnpm (a nodejs package manager) with workspaces - which may be completely different. Can open another issue if needed.

pnpm creates a symlinked structure (junctions on Windows) inside node_modules. git clean -ffdx . reports warnings like this:

warning: could not open directory 'node_modules/copy-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/@webassemblyjs/wasm-edit/node_modules/@webassemblyjs/helper-wasm-section/node_modules/@webassemblyjs/wasm-gen/node_modules/@webassemblyjs/ast/node_modules/@webassemblyjs/helper-numbers/node_modules/@webassemblyjs/floating-point-hex-parser/': Function not implemented

I'm not sure, whether the folder might look like "recursive" - directory enumeration above is not.

However, most notably, "node_modules" is in .gitignore - git status is fine, and so I'd think git clean -ffdx should just remove any junction as soon as it finds one, without traversing.

[...]/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/node_modules/webpack/node_modules/terser-webpack-plugin/[...]

That almost looks like a symlink loop, but then it ends in:

[...]/@webassemblyjs/wasm-gen/node_modules/@webassemblyjs/ast/node_modules/@webassemblyjs/helper-numbers/node_modules/@webassemblyjs/floating-point-hex-parser/

In any case, it is an awfully long path. I am just surprised that the error message suggests ENOSYS when it probably should be ENAMETOOLONG. I guess The reason for that is that we default to ENOSYS when encountering unknown error conditions.

Now, it would be really interesting if you could build Git for Windows, patch compat/mingw.c to report the unknown error number (via inserting default: error("unknown winerr: %ld", winerr); break; into that long `switch statement) and then tell us that number, so that we can fix the error message.

You could also see whether my tentative diff would fix the problem on your side.

I'm working on converting a big monorepo to pnpm and I have intentionally introduced cyclic symlinks (kinda like the above), and now hit this problem with git clean where it seems to keep walking down the symlinks in Windows.

Is there anything I can try here? Are the diffs provided above still accurate?

Testing the "tentative diff" (#3358 (comment)), I get:

.../@types/node/node_modules/@types/node/node_modules/@types/node/': Unknown error

As expected, it seems.

But, why does git walk down the entire loop? It doesn't behave like this on the same structure in Linux/macOS; the clean properly deletes the directory without recursing. It seems like this patch is just intending to change the error, but as noted in previous replies, it seems like it shouldn't be recursing at all.

Also, going via WSL2 into the same dir behaves properly; so the symlink information and not recursing seems to work, but not in the windows version of git, it seems.

I've been digging, and I think I've gotten to the root. finddata2dirent checks for IO_REPARSE_TAG_SYMLINK, but the symlinks created by pnpm are IO_REPARSE_TAG_MOUNT_POINT. The latter seems to be more commonly associated with git's symlink handling and switching the check makes it match the code in mingw_is_mount_point exactly.

I am not an expert in these syscalls, though, but just this fixes the problem for me:

diff --git a/compat/win32/dirent.c b/compat/win32/dirent.c
index 87063101f5..3e543b51ef 100644
--- a/compat/win32/dirent.c
+++ b/compat/win32/dirent.c
@@ -19,7 +19,7 @@ static inline void finddata2dirent(struct dirent *ent, WIN32_FIND_DATAW *fdata)
 
 	/* Set file type, based on WIN32_FIND_DATA */
 	if ((fdata->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)
-			&& fdata->dwReserved0 == IO_REPARSE_TAG_SYMLINK)
+			&& fdata->dwReserved0 == IO_REPARSE_TAG_MOUNT_POINT)
 		ent->d_type = DT_LNK;
 	else if (fdata->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
 		ent->d_type = DT_DIR;

I've sent #4383 with a test which shows the behavior change. I'm definitely interested in some expert opinions here.

I think this may be a regression, because #2268 claims to have fixed this

Stepped through in the debugger, it does attempt to unlink the junction, but DeleteFileW, _wunlink and _wrmdir all fail, after _wrmdir GetLastError is 5.

I don't know anymore.. the error I saw when I reported #5320 seems to have disappeared without me having changed anything.

As far as the spurious warning, this is coming from

#0  open_cached_dir (cdir=0x5f5fc0, dir=0x5ff5e0, untracked=0x0,
    istate=0x51a160c0100, path=0x5f5fa0, check_only=0) at dir.c:2580
#1  0x00007ff653ce71a0 in read_directory_recursive (dir=0x5ff5e0,
    istate=0x51a160c0100,
    base=0x51a16121c80 "foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/"...,
    baselen=236, untracked=0x0, check_only=0, stop_at_first_file=0,
    pathspec=0x5ff520) at dir.c:2707
...
#176 0x00007ff653ce5e95 in treat_directory (dir=0x5ff5e0,
    istate=0x51a160c0100, untracked=0x0, gitdirname=0x51a160209a0 "foo/",
    len=4, baselen=0, excluded=0, pathspec=0x5ff520) at dir.c:2157
#177 0x00007ff653ce6907 in treat_path (dir=0x5ff5e0, untracked=0x0,
    cdir=0x5ff340, istate=0x51a160c0100, path=0x5ff320, baselen=0,
    pathspec=0x5ff520) at dir.c:2491
#178 0x00007ff653ce7234 in read_directory_recursive (dir=0x5ff5e0,
    istate=0x51a160c0100, base=0x7ff653f63fd6 <__ac_HASH_UPPER+1222> "",
    baselen=0, untracked=0x0, check_only=0, stop_at_first_file=0,
    pathspec=0x5ff520) at dir.c:2716
#179 0x00007ff653ce82f6 in read_directory (dir=0x5ff5e0, istate=0x51a160c0100,
    path=0x7ff653f63fd6 <__ac_HASH_UPPER+1222> "", len=0, pathspec=0x5ff520)
    at dir.c:3150
#180 0x00007ff653ce1f30 in fill_directory (dir=0x5ff5e0, istate=0x51a160c0100,
    pathspec=0x5ff520) at dir.c:264
#181 0x00007ff653b5c86d in cmd_clean (argc=0, argv=0x51a16020280, prefix=0x0,
    repo=0x7ff65401e380 <the_repo>) at builtin/clean.c:1066

msys2/msys2-autobuild#108 is back. Could someone please look at this on git-for-windows's side? Personally, I think it makes sense to try to have "what is a symlink" agree between the Cygwin and MINGW pieces of git-for-windows, because Git has a habit of calling shell scripts to do things and those scripts would see symlinks where a builtin implementation would not. But perhaps just some sort of band-aid in dir.c (maybe a flag that cmd_clean can set that says "don't recurse into untracked mountpoints") would be enough for this particular scenario?

It seems that in some scenarios, git clean hangs rather than warning or failing in the face of recursive junctions. msys2/msys2-autobuild#110