https://bugs.winehq.org/show_bug.cgi?id=51687
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #70557|0 |1 is obsolete| |
--- Comment #4 from Matías Zúñiga matias.nicolas.zc@gmail.com --- Created attachment 70571 --> https://bugs.winehq.org/attachment.cgi?id=70571 GetMappedFileName: Return nt filename and resolve DOS drive path
(In reply to Zebediah Figura from comment #3)
We should probably be resolving DOS drive symlinks on the server side (or in ntdll?) rather than in kernelbase; the test failure sort of hints at that.
??\ isn't the unix prefix; it's the global NT namespace prefix.
Unfortunately our handling of file paths is a little weird; the summary is that we basically treat drive letters as the canonical form even though they aren't on Windows. I've had some ideas on how to fix it, but unfortunately none of them are particularly pretty, and I haven't yet found an application that isn't satisfied with easier workarounds (such as resolving NT symlinks manually before returning them).
I understand. I made the changes in kernelbase, because that's where QueryDosDeviceW was available.
In the new (attached) version, i move the read_nt_symlink helper to ntdll.RtlReadNtSymlink, and use it directly instead of calling QueryDosDeviceW. Since read_nt_symlink is a small piece of code, maybe it should be copied to virtual.c, instead of exporting it in ntdll.
The regressions tests pass, and 4 todos were removed.