clean cannot remove paths with long names

[mathstuf]

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

Setup

• 2.27.0.windows.1 64-bit
• commit 907ab10

$ git --version --build-options

The machine is over a remote connection; copy/pasting back isn't easy.

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

$ cmd.exe /c ver
Windows 10

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

Stock install. Shouldn't matter here though.

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

Not that I know of.

Details

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

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

git clean -ffdx

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

Clean directory.

• What actually happened instead?

It complains that one path name is too long. Git-for-Windows should translate paths to Extended Path representation if this occurs (\\?\).

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

Irrelevant.

[rimrul]

Do you have core.longpaths enabled?

[mathstuf]

Hmm. If it's not asked in the installer, no.

[mathstuf]

But I don't remember changing the defaults for it either if it is there.

[JasonGore]

I am also seeing long filename errors that didn't occur with 2.26 and earlier. The filenames themselves are the same lengths. core.longpaths was always set to false and previously wasn't needed for these situations. (At least the situations I'm seeing failures in now.)

[dscho]

Does anybody have a real MCVE? (The provided command git clean --ffdx does not reproduce the problem here and is therefore not Verifiable.)

[mathstuf]

I'll try and make one.

[mathstuf]

longname="really long path name"
git init
touch "$longname.txt"
for x in {1..20}; do
  mkdir "$longname$x"
  mv really* "$longname$x"
done
git clean -ffdxn
git clean -ffdx

[mathstuf]

Setting core.longpaths does work. Is there any downside to setting this by default? Or adding this hint to the error message for the "filename too long" case?

[dscho]

Setting core.longpaths does work. Is there any downside to setting this by default?

Yes. There are Windows versions where even Explorer cannot handle such long paths, so users could get stuck with a worktree cloned by Git that simply can't be deleted.

Or adding this hint to the error message for the "filename too long" case?

I have not seen any verbatim error message, so I cannot say whether the error message is provided by Git itself (in which case we could fix it, or more correctly: I would ask you to fix it and open a PR), or whether Git uses strerror() to generate it (in which case we cannot really fix the error message because strerror() is generic and does not necessarily get called only in scenarios where core.longPaths might help).

[mathstuf]

The actual error message can be seen here:

warning: failed to remove build/superbuild/smtk/build/PluginTests/c3a5b5da/build/plugin/build/lib/cmake/read-and-write-resource-manager-state/read-and-write-resource-manager-state-plugin-read_and_write_resource_manager_state_paraview_plugins-targets-depends.cmake: Filename too long

[rimrul]

That seems to be one of the 5 warning_errno(_(msg_warn_remove_failed), ... lines in builtin/clean.c. We could add some advice to it if saved_errno == ENAMETOOLONG

[dscho]

Closing as stale.