It may be clearer to use hex instead of decimal:

D:\source\python-sample\venv\Scripts\python.exe D:\source\python-sample\main.py 
$RECYCLE.BIN
0x0
0x19d10000000000000000

aspnetcore
0x0
0x7df0000000000000000

cpython
0x0
0x61c90000000000000000

Euler
0x0
0x613f0000000000000000

file.txt
0x12
0x6000000000000000012

gobook
0x0
0x61140000000000000000

gobook2
0x0
0x61250000000000000000

gopl.io
0x0
0x60760000000000000000

leveldb
0x0
0x5e490000000000000000

link_file.txt
0x12
0x6000000000000000012

oceanbase
0x0
0x57970000000000000000

source
0x0
0x19d30000000000000000

symlink_dir
0x0
0xdff30000000000000000

symlink_file.txt
0x13
0x6000000000000000012

System Volume Information
0x0
0x0

test-py
0x0
0xdff30000000000000000

It seems that entry.inode() drops the highest bits and only returns lower bits.

There is a comment on Microsoft website about file id and ReFS:

https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-by_handle_file_information

The implementation of entry.inode() is incorrect. It drops stat.st_ino_high and only includes stat.st_ino. See posixmodule.c:15136:

static PyObject *
os_DirEntry_inode_impl(DirEntry *self)
/*[clinic end generated code: output=156bb3a72162440e input=3ee7b872ae8649f0]*/
{
#ifdef MS_WINDOWS
    if (!self->got_file_index) {
        ...

        self->win32_file_index = stat.st_ino;
        self->got_file_index = 1;
    }
    static_assert(sizeof(unsigned long long) >= sizeof(self->win32_file_index),
                  "DirEntry.win32_file_index is larger than unsigned long long");
    return PyLong_FromUnsignedLongLong(self->win32_file_index);
#else /* POSIX */
    ...
#endif
}

@zooba What is ReFS?

@zooba What is ReFS?

ReFS uses 128-bit file ids, while NTFS does not. entry.inode() drops the higher 64 bits, and it is the issue.

@gvanrossum It's a file system. Been around for 10+ years at this point, but only recently became available to non-server installs (and it's the preferred file system for Dev Drive, so we can expect usage to increase).

I think besides #111294 , it may be possible to add another environment to the Test workflow, maybe named "Windows (x64) with ReFS". Is that possible?

I also notice that another test case fails on ReFS and I'm considering whether to raise a new issue.

We normally set up buildbots for specific scenarios like this. GitHub already has too many checks to be efficient for PRs, and we don't need to validate every possible configuration pre-commit.

Please do raise a new issue. We want to get things right on ReFS (but also be aware that some tests may have an implicit assumption of NTFS that's at fault (and also also be aware that newer Windows Insider builds have the newer stat() API implementation, which may have otherwise undiscovered issues, so your precise build number may be relevant)).

OK, I will raise it tomorrow. The name of the test case is like "send_file" (I don't quite remember it now) and it may be related to I/O model.