[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 #70571|0                           |1
        is obsolete|                            |

--- Comment #6 from Matías Zúñiga <matias.nicolas.zc at gmail.com> ---
Created attachment 70579
  --> https://bugs.winehq.org/attachment.cgi?id=70579
GetMappedFileName: Return nt filename and resolve DOS drive path

(In reply to Zebediah Figura from comment #5)
> (In reply to Matías Zúñiga from comment #4)
> > 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.
> 
> Better, but I still have some comments:
> 
> * You can't just add new helpers from ntdll; our exports have to match
> native. That said, if you've fixed NtQueryVirtualMemory, you shouldn't need
> to make any changes to kernelbase.
> 
> * add_device_path() works, though on the other hand "\??\" is also a symlink
> and can be resolved as such. I.e. it should be a matter of just taking the
> path that's already returned, and (repeatedly) resolving all of the symlinks.
> 
> * I don't understand why you should need to make any changes to the server
> at all.

Right, that's what I thought. Since its a relavevely small helper function, I
can just copy the code to virtual.c

I was stripping the \??\ prefix because that's what QueryDosDeviceW required,
but since NtOpenSymbolicLinkObject works with the prefix I can use that. Will
the paths returned by get_mapping_filename always be in the form "\??\X:" if it
does contain a drive path to resolve?

An updated patch is attached.

-- 
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.