On 3/5/20 10:18 AM, Zebediah Figura wrote:
On 3/4/20 9:04 PM, Zebediah Figura wrote:
Signed-off-by: Zebediah Figura zfigura@codeweavers.com
v2: Shift the device number by 4 bytes, since the lower 4 bytes are used by the volume serial number.
dlls/ntdll/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c index 7dfb0a4800e..2aa5d8f979f 100644 --- a/dlls/ntdll/file.c +++ b/dlls/ntdll/file.c @@ -2508,7 +2508,7 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, else { FILE_ID_INFORMATION *info = ptr;
info->VolumeSerialNumber = 0; /* FIXME */
info->VolumeSerialNumber = (ULONGLONG)st.st_dev << 32; memset( &info->FileId, 0, sizeof(info->FileId) ); *(ULONGLONG *)&info->FileId = st.st_ino; }
Based on Alistair's comments and some further research, this probably isn't a great solution.
It turns out that NTFS drives actually have 64-bit serial numbers, but that's truncated to 32 bits for most APIs. More importantly, the serial number doesn't change across boots, and should be unique for different removable drives—neither of which, I understand, are guarantees for st_dev.
Actually, on further examination, I don't think either of our uses of is_same_file() are necessary, so I'll try to get rid of those instead.
Meh, I was wrong. The MoveFile() call can go away, but the CopyFile() call apparently really needs to stay.
I guess using the real volume serial number is the best fix here, though I'd welcome better ideas.
(Note that we can't just compare the file name—I checked, and CopyFile() similarly fails for hard links.)