[PATCH v2 1/2] ntdll: Return a unique volume number from NtQueryInformationFile(FileIdInformation).
ken at codeweavers.com
Thu Mar 5 10:53:11 CST 2020
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,
>> 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.
More information about the wine-devel