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