Enable long path support where it's supported

[se35710]

For some operations, long path support is available by prefixing the path with \\?\. This includes all rm operations, which would help with uninstalling applications that were unzipped with 7zip.

Maybe a core function could be added to prefix the path, or functions (rm_longpath for example) for commands where it is supported? Or just change all instances of rm to rm "\\?\$(<function> $<variable>)"

I could create a PR once I know what way to go, and possible name suggestions for the function(s).

[lukesampson]

I tried the \\?\ workaround a while ago. If I remember correctly 7-zip didn't support it. It may also have been msiexec. We need something that works with both, and innounp and possibly some others I haven't thought of. I think it's up to individual programs whether they support that prefix, so it's not a very good workaround if it doesn't work everywhere.

It looks like Windows 10 adds support for long paths with a registry change (see here and here). I think it would be best to focus on this rather than other workarounds.

I think the best thing to do is add a diagnostic test to scoop checkup

• If username > 10 characters
  • If Windows version >= 10.1607, check for the registry fix and if not present, suggest implementing it with instructions on how to do so.
  • Else show a warning that you may have trouble with long paths, suggest the $env:SCOOP workaround if you do

How does that sound?

[se35710]

For those who are not administrators on their PCs? And all Windows 7 / Server 2012 users? I still think at least for removing apps, the \\?\ workaround should be enabled. During upgrades, the uninstall step is run, correct? It would help a lot if upgrades would just work out of the box, I think.

Maybe a combination of both \\?\ when uninstalling and adding it to checkup?