#510 ino_t is only 16bit

[Jason Schulz]

The ino_t type has only 16bits. Arguably, it isn't usable as a POSIX inode analogue. It might provide more POSIXish semantics if the type were extended to 64bits (or 32bits for Windows 32bit).

One possibility to synthesize a usable inode number is included below...

ino_t to_inode(const char* path) {

    // synthesize inode 

    BY_HANDLE_FILE_INFORMATION fi;
    HANDLE h;

    h = CreateFile(path, 0, 0, NULL, OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS | FILE_ATTRIBUTE_READONLY, NULL);

    if (h == INVALID_HANDLE_VALUE)
            return -1;

    if (!GetFileInformationByHandle(h, &fi)) {
            CloseHandle (h);
            return -1;
    }

    return ((uint64_t) fi.nFileIndexHigh << 32) | \
               ((uint64_t) fi.nFileIndexLow);

    if (!CloseHandle(h))
    return -1;

}

If I'm not mistaken, this will provide a unique identifier for NTFS. However, I'm not sure if it's usable for other filesystems.

[Kai Tietz]

Hi Jason,

this issue is one of those you show that you have a misconception about what mingw-target is. Mingw-w64 provides MS' compatible runtime, which means all but it is POSIX compiant. We try our best to provide some optional functionality from POSIX-world to our runtime, as long as it doesn't violates that one defined by MS.

Sadly, MS specifies ino_t as 16-bit (unsigned short). This type is used at some places (eg for stat-structure), so we can't change ino_t's type as it would leads to wrong structure-size/layout.