GetFinalPathNameByHandle attempts to translate a volume mount point to an NT volume name using QueryDosDevice, but this can only succeed if the mount point is a drive letter. When GetVolumeNameForVolumeMountPoint encounters a similiar situation, it emits a fixme message.
When attempting to translate a volume mount point to an NT volume name with GetFinalPathNameByHandle, for a mount point that is not a drive letter, emit a fixme message.
Signed-off-by: Jeff Smith whydoubt@gmail.com --- dlls/kernel32/file.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dlls/kernel32/file.c b/dlls/kernel32/file.c index 2b6a13fc0d..2d52b0a165 100644 --- a/dlls/kernel32/file.c +++ b/dlls/kernel32/file.c @@ -1442,6 +1442,14 @@ DWORD WINAPI GetFinalPathNameByHandleW(HANDLE file, LPWSTR path, DWORD charcount { WCHAR nt_prefix[MAX_PATH];
+ /* if length of drive_part is > 3 then it must be a mounted folder */ + if (drive_part_len > 3) + { + FIXME("Mounted Folders are not yet supported\n"); + SetLastError( ERROR_NOT_A_REPARSE_POINT ); + return 0; + } + /* QueryDosDeviceW sets error code on failure */ drive_part[drive_part_len - 1] = 0; if (!QueryDosDeviceW( drive_part, nt_prefix, MAX_PATH ))
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=56761
Your paranoid android.
=== debian10 (64 bit WoW report) ===
kernel32: debugger.c:320: Test failed: GetThreadContext failed: 5
Hi Jeff,
It would be better if you could add some tests for this. For example, add a test that shows the failures on wine and then next patch fix it and remove todo_wines.
And is this for winehq bug 47787?
Thanks, Zhiyi
On 9/23/19 1:10 PM, Jeff Smith wrote:
GetFinalPathNameByHandle attempts to translate a volume mount point to an NT volume name using QueryDosDevice, but this can only succeed if the mount point is a drive letter. When GetVolumeNameForVolumeMountPoint encounters a similiar situation, it emits a fixme message.
When attempting to translate a volume mount point to an NT volume name with GetFinalPathNameByHandle, for a mount point that is not a drive letter, emit a fixme message.
Signed-off-by: Jeff Smith whydoubt@gmail.com
dlls/kernel32/file.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dlls/kernel32/file.c b/dlls/kernel32/file.c index 2b6a13fc0d..2d52b0a165 100644 --- a/dlls/kernel32/file.c +++ b/dlls/kernel32/file.c @@ -1442,6 +1442,14 @@ DWORD WINAPI GetFinalPathNameByHandleW(HANDLE file, LPWSTR path, DWORD charcount { WCHAR nt_prefix[MAX_PATH];
/* if length of drive_part is > 3 then it must be a mounted folder */
if (drive_part_len > 3)
{
FIXME("Mounted Folders are not yet supported\n");
SetLastError( ERROR_NOT_A_REPARSE_POINT );
return 0;
}
/* QueryDosDeviceW sets error code on failure */ drive_part[drive_part_len - 1] = 0; if (!QueryDosDeviceW( drive_part, nt_prefix, MAX_PATH ))