Editing Inode (section)

== In non-Unix systems ==
* [[NTFS]] has a master file table (MFT) storing files in a B-tree. Each entry has a "fileID", analogous to the inode number, that uniquely refers to this entry.<ref>{{cite web |title=Does Windows have Inode Numbers like Linux? |url=https://stackoverflow.com/a/42475374 |website=Stack Overflow}}</ref> The three timestamps, a device ID, attributes, reference count, and file sizes are found in the entry, but unlike in POSIX the permissions are expressed through a different API.<ref name=win32stat>{{cite web |title=GetFileInformationByHandle function (fileapi.h) - Win32 apps |url=https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle |website=docs.microsoft.com |date=27 July 2022 |language=en-us}}</ref> The on-disk layout is more complex.<ref>{{cite web |title=[MS-FSCC]: NTFS Attribute Types |url=https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/a82e9105-2405-4e37-b2c3-28c773902d85 |website=docs.microsoft.com |date=20 September 2023 |language=en-us}}</ref> The earlier FAT file systems did not have such a table and were incapable of making hard links.
** NTFS also has a concept of inlining small files into the MFT entry.<ref>{{Cite web|url=https://superuser.com/a/1185466|title = Windows - Maximum size of file that can be stored entirely in NTFS Master File Table (MFT)}}</ref>
** The derived [[ReFS]] has a homologous MFT. ReFS has a 128-bit file ID; this extension was also backported to NTFS, which originally had a 64-bit file ID.<ref name=win32stat/>
* The same stat-like {{tt|GetFileInformationByHandle}} API can be used on [[Cluster Shared Volumes]], so it presumably has a similar concept of a file ID.<ref name=win32stat/>