os.stat('<filename>')[stat.ST_INO] on Windows

[Patrick Useldinger]

What does the above yield on Windows? Are inodes supported on Windows
NTFS, FAT, FAT32?

 

[jepler]

What does the above yield on Windows? Are inodes supported on Windows
NTFS, FAT, FAT32?

Refer to the operating system documentation (msdn.microsoft.com?). os.stat is
mostly a wrapper around whatever the OS provides. A quick glance at Python
source code shows that maybe _stati64() or _wistat64() is the actual function
used on windows.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCIkDoJd01MZaTXX0RAgACAJ9+H7OKtjIrJdyK/UArnK4OoEEY7QCcD7WO
WuKIgnPXIvbd+Hx5iNZ2/L8=
=Fj/b
-----END PGP SIGNATURE-----

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

> Refer to the operating system documentation (msdn.microsoft.com?). os.stat is
mostly a wrapper around whatever the OS provides. A quick glance at Python
source code shows that maybe _stati64() or _wistat64() is the actual function
used on windows.

That doesn't really help: MSDN says

"""Number of the information node (the inode) for the file
(UNIX-specific). On UNIX file systems, the inode describes the file date
and time stamps, permissions, and content. When files are hard-linked to
one another, they share the same inode. The inode, and therefore st_ino,
has no meaning in the FAT, HPFS, or NTFS file systems.
"""

So we know it has no meaning, but they won't tell us what its value is.
Fortunately, MS ships the source of the CRT in VC, so we know st_ino
is always 0 (as are st_uid and st_gid).

Regards,
Martin

 

[Tim Roberts]

What does the above yield on Windows?
0.

Are inodes supported on Windows NTFS, FAT, FAT32?

No. Inodes are strictly a Unix filesystem concept.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

No. Inodes are strictly a Unix filesystem concept.

I disagree. NTFS MFT records are so similar to inodes
that their numbers could well be used in st_ino (except
that they are 64-bit quantities, whereas st_ino
typically has only 32 bits).

Regards,
Martin

 

[Tim Roberts]

I disagree. NTFS MFT records are so similar to inodes
that their numbers could well be used in st_ino (except
that they are 64-bit quantities, whereas st_ino
typically has only 32 bits).

Hmmm, yes, but nearly 100% of Unix geeks have seen an inode number in their
programming adventures, whereas I'll bet not 1 in 10,000 Windows hardliners
has ever seen an MFT entry.

There are things you can do with an inode number, but there's nothing you
can do with an MFT ordinal.

So, I'll grant that my answer was too specific, but I still believe the
answer to the original question is "no".

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Hmmm, yes, but nearly 100% of Unix geeks have seen an inode number in their
programming adventures, whereas I'll bet not 1 in 10,000 Windows hardliners
has ever seen an MFT entry.

That is going to change. At my university, students learn what an MFT
record is and how it is structured as part of the operating system
course, just as they learn what an inode is.

I'll grant you that a MFT records are less visible, primarily because
people don't do hard links all that often. That might be changing as
well.

There are things you can do with an inode number, but there's nothing you
can do with an MFT ordinal.

Like what? On NTFS and Win32, you can even convert an inode number
efficiently back to a path name (actually, all path names), something
you cannot do on a typical Unix system (atleast not efficiently).

So, I'll grant that my answer was too specific, but I still believe the
answer to the original question is "no".

Yes, but that's the stupidity of the MS C library, which doesn't use
the nFileIndexHigh/nFileIndexLow fields of the
BY_HANDLE_FILE_INFORMATION structure (it also is the stupidity of the
Win32 API, which claims that you need an open file to support the
notion of a file identifier).

Regards,
Martin