stat.inode is not reliable as a check for samefile() if using network files on Windows

[sunito]

I was baffled for quite a while, when I found that samefile("N:\\A", "N:\\B") can return true for (different) network files on Windows 10 running in VirtualBox.
I then found, that stat(file_name) does not yield consistent .inode values.

Steps to reproduce:

1. Start Windows 10 in a VirtualBox with a (writable) shared folder.
   Let's assume that this folder is mounted to drive "N:".

2. Check, that they are not constant:

julia> [stat("N:\\").inode for i in 1:9]
  9-element Vector{UInt64}:
   0x00000000a6a14aa0
   0x00000000ac184aa0
   0x00000000a6973aa0
   0x00000000a1596010
   0x00000000a69caaa0
   0x00000000a276a840
   0x000000009dc7a5e0
   0x00000000a6974aa0
   0x00000000a69dbaa0

4. Check that some inode values repeat:
   julia> length(unique([stat("I:\\").inode for i in 1:99]))
74
5. After a while the inode values will stay the same (at least on my machine):
   julia> length(unique([stat("I:\\").inode for i in 1:99]))
1

The shared file system is ext4 on a linux machine.

julia> versioninfo()
Julia Version 1.9.2
Commit e4ee485e90 (2023-07-05 09:39 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 2 × AMD Ryzen 7 4700U with Radeon Graphics
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, znver2)
  Threads: 1 on 2 virtual cores

[vtjnash]

The device number should be different, and the pair of those should form a unique identifier of the file. Is that not true in what you are seeing for Filesystem.samefile?

[sunito]

No, this is not true in my setup.

I've just checked it: The device number is always the same: 0x0000000000010302 (=66306).
julia> length(unique([stat("I:\\").device for i in 1:99]))
1

julia> length(unique([( s=stat("I:\\"); (s.inode, s.device) ) for i in 1:99]))
35 # But should be 99

[sunito]

On Windows 7 and Julia 1.8, the results are quite similar.
In particular, the device number is the same (0x0000000000010302 = 66306)

julia> versioninfo()
Julia Version 1.8.5
Commit 17cfb8e65e (2023-01-08 06:45 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 4 × AMD Ryzen 7 4700U with Radeon Graphics
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-13.0.1 (ORCJIT, znver2)
  Threads: 1 on 4 virtual cores

[sunito]

I came across this bug when using cp() and mv() with force=true

I'll include part of the original error message for others to find this issue:
ArgumentError

'src' and 'dst' refer to the same file/dir. This is not supported.
`src` refers to: \\\\Vboxsvr\\111\\one\\file\\... 
`dst` refers to: \\\\Vboxsvr\\111\\other\\file\\... 

[vtjnash]

libuv sets this value to the VolumeSerialNumber. Could you print those out and see if they are the same?https://github.com/libuv/libuv/blob/d09441ca03e399fe641da88624c8ea0476967187/src/win/fs.c#L1869
https://www.lifewire.com/how-to-find-a-drives-volume-label-or-serial-number-2624494

Possibly instead it should parse the Volume GUID. Could you confirm if this value looks unique:
https://www.wintips.org/how-to-find-volume-guid-list-volume-guids-per-disk/

[sunito]

Yes, the volume serial number is indeed the same as the stat.device number: "0001-0302"

The described method for retrieving the volume GUID only works for "normal" drives, not network drives. So, I was not able to get obtain this value for my network volume.
(Btw, for my "C:"-partition, the value was clearly different from its volume serial number.)

Actually, why do you ask about the device ids? The problem in my case is that the inode values are not stable.

[vtjnash]

That is strange. This is seems to be documented to be a guarantee by the NT kernel here: https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_id_info. But maybe this FILE_ID_128 is not the same as the LARGE_INTEGER one that is exposed by FileAllInformation or FILE_STAT_INFORMATION

[sunito]

Or maybe files on network drives are not regarded as regular files and theses structures are not supposed to have meaningful content. Just guessing.