https://bugs.winehq.org/show_bug.cgi?id=42446
--- Comment #32 from Stan markau0@lycos.com --- The printout of GetVolumePathNameW volumenameW is a path with forward slashes ie
"C:/home/user/.wine/drive_c/Program Files/App/App.exe"
then the loop code traverses that path starting at the end and moving toward the start but the loop code is searching for backslash's in volumenameW which don't exist and the loop breaks after one iteration and the return volume path is the original path with slash's converted to double backslashes with an extra backslash on the end which is useless for GetVolumeInformationW which flags an error.
Original entry path with slash's in GetVolumePathNameW volumenameW
"C:/Program Files/Native Instruments/Native Access/Native Access.exe"
The returned volume path with backslash's from GetVolumePathNameW
"C:\Program Files\Native Instruments\Native Access\Native Access.exe\"
This has got to affect a lot of Windows apps and not just Native Access, and the only thing I can think of is that most Windows apps are ignoring the GetVolumeInformationW error return whereas Native Access takes the error to mean that it's being run from a read only filesystem and therefore the GetVolumePathNameW bug has been brought out into the open via the Native Access read only error.
The GetVolumePathNameW loop does this
Since we can have very complicated drive/path * relationships on Unix systems, due to symbolic links, the safest way to * handle this is to start with the full path and work our way back folder by * folder unil we find a folder on a different drive (or run out of folders).