[PATCH v2 1/2] ntdll: Return a unique volume number from NtQueryInformationFile(FileIdInformation).

Zebediah Figura zfigura at codeweavers.com
Thu Mar 5 11:08:36 CST 2020



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



More information about the wine-devel mailing list