git clean with junctions that have cycles causes warnings

[arinwt]

• 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.23.0.windows.1
cpu: x86_64
built from commit: 4db2e5cc9e1522131a039cbad3970f147a39f0ce
sizeof-long: 4
sizeof-size_t: 8

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

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18362.295]

• 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: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled

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

Using npm with circular dependencies.

Details

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

Bash

• 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.

I based this off the test case for #2268. I ran this in an empty directory to init a repository and create a circular junction. Then the git clean -dfx will generate an unwanted warning.

mkdir target &&
>target/dont-clean-me &&
git init with-mountpoint &&
cmd //c "mklink /j with-mountpoint\\mountpoint target" &&
cmd //c "mklink /j target\\cycle with-mountpoint" &&
git -C with-mountpoint clean -dfx

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

I expect the mountpoint/ junction point to be removed without warnings.

Initialized empty Git repository in <absolute-path>/with-mountpoint/.git/
Junction created for with-mountpoint\mountpoint <<===>> target
Junction created for target\cycle <<===>> with-mountpoint
Removing mountpoint/

• What actually happened instead?

A warning is displayed during git clean, I believe for too long filename (by trying to enumerate a cycle of junction points).

Initialized empty Git repository in <absolute-path>/with-mountpoint/.git/
Junction created for with-mountpoint\mountpoint <<===>> target
Junction created for target\cycle <<===>> with-mountpoint
warning: could not open directory 'mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/mountpoint/cycle/': Function not implemented
Removing mountpoint/

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

Above steps can reproduce with new repository. It will likely occur for any repo with circular npm dependencies that are locally linked which create junctions automatically. Although these are not desirable, I would expect that git clean would not even try to traverse these paths as indicated in the docs.

[dscho]

Hmmm :-(

I won't have time to look into this myself, so here are a couple of pointers:

• the easiest way to figure this one out would be to run this in Git for Windows' SDK (https://gitforwindows.org/#download-sdk), in gdb
• do build it first, using sdk cd git && make -j$(nproc)
• you can run the just-built git.exe without installing it via /usr/src/git/git.exe --exec-path=/usr/src/git [...] (prefix that with gdb -args to run it in gdb)
• put a breakpoint on warning() via b warning (I believe)
• start it in gdb via r
• once it stops, look at the stacktrace via bt
• you can even navigate the stacktrace via up and down and look at the source code via l and inspect variables via p <name>

[arinwt]

This looks to actually be a duplicate of #607 and is resolved in 2.28 by #2268. (went through several PR iterations, starting with #1414)

[dscho]

@arinwt thank you for your diligence!