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

[Ken Thomases]

On Mar 5, 2020, at 10:18 AM, Zebediah Figura <zfigura at codeweavers.com> 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.

For what it's worth, macOS can provide a UUID for certain volumes, depending (I think) on the partition table type.  I would think that Linux could access that, too.

-Ken