https://bugs.winehq.org/show_bug.cgi?id=51687
Matías Zúñiga matias.nicolas.zc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #70571|0 |1 is obsolete| |
--- Comment #6 from Matías Zúñiga matias.nicolas.zc@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.