On Wednesday, 19 September 2018 at 10:29:11 UTC, Vladimir Panteleev wrote:
- GetFullPathName is documented as also having the MAX_PATH limit, but the framework seems to use it for normalization BEFORE prepending the prefix.

https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-getfullpathnamea

That part is erroneous :)
Recent additions to msdn are too often incompetent, e.g. long path registry switch in windows 10 doesn't enable the feature, it's only the first of two gates, manifest is not optional. Don't ask me who does it. They can't even get backslashes right. Passing unparsed path to GetFullPathName makes no sense because such unparsed path must be already full normalized path, and it doesn't have MAX_PATH limit, probably because it doesn't talk to file system.

- GetFullPathName has a big warning on it about how you shouldn't use it in multithreaded programs.

I wonder about that too, shouldn't the system do the same to resolve the absolute path? Theoretically it can keep an open handle to the current directory and get its path from that.

Reply via email to