ericwj / gowindows Goto Github PK

@rasky I don't know whether fixLongPath fixes many issues. The prefixes aren't specific to long paths. I don't have a complete oversight readily available for the issues with the API's, but some of those I see with Join are very common accross path/filepath.

There is a whole series of issues evidencing that there are string manipulations that are just wrong. Often the first \ is stripped off the prefix, for example. The \\.\ prefix isn't recognized at all and there are lots of cases where \\?\ is being ignored. After all, \\?\ means do not parse i.e. leave unmodified. I believe Clean is a major source of issues and that function is used in several other API's.

Fixing any part of EvalSymlinks is not an advantage imho. Better leave it broken and deprecate it.

Then also don't introduce a drop-in replacement that will suffer many of the same issues. There are much better ways of solving the problems at hand. I didn't mention any use of GetFinalPathNameByHandle will have to iterate flags until there is a result that is not 'Path not found' or another error and then still the developer might have to hint at how to call that API to get the correct result. On top of that, it is bad performance wise to have string arguments and do the retries for perhaps thousands of files in succession.

Input: an API name & required arguments. From command line args or stdin?
Test input: a flag and output or error string; Go API not called.

Output: a pathname. To stdout?

Error: a Windows error code and associated Go string. To stderr?

Analysis: comparison of output with expected result lives in external script?

Process: do you expect to modify this Go code?

Note: I'm not sure that this effort will yield any bugfixes in Go. The Windows maintainer is not a Google employee, and has opposed bug reports and proposals on grounds that they could break existing programs, without giving real-world examples of such programs. The Go team is reluctant to overrule him. There are few active contributors to the Windows port to advocate fixes. We may only be able to get something added to x/sys/windows. Worst case, we'll have to publish a third-party package.

When you're ready to report the problems you've found to the Go project, I suggest you:

a) open a new Go issue (and close the "EvalSymlinks..." issue)
b) reference the CL you create in the issue attach the files needed to reproduce the bugs
c) include the expected and actual output in the issue text, as a code block
d) avoid any indication of grumpiness (even if justified :-)

Don't point to this repo, or mention me. The Windows maintainer bears a grudge because of golang/go#32088 :-/

Perhaps it is wise to discuss the expected values against which to test go API's.

For example [System.IO.Path]::GetFullPath("\\?\.") returns "\\?\." which would in my opinion be suitable for Abs, too, but I don't want to get shot down making such claims without at least discussing that.

Another example would be to compare what EvalSymLinks does on Linux before changing the issue title and text of 40104. Can you show that it for example never returns anything 'unstable' like a volume GUID as it does on Windows? Does it return eventually at best say /dev/sda or similar? Sure I have that website which claims it is a good idea to get a stable path from EvalSymLinks, but that is just one corner of the Internet.