[Bug 51687] GetMappedFileNameA/W implementation breaks RiotClient updates.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51687

Matías Zúñiga <matias.nicolas.zc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #70557|0                           |1
        is obsolete|                            |

--- Comment #4 from Matías Zúñiga <matias.nicolas.zc at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.