Large-file support: Difference between revisions

Revision as of 13:45, 20 March 2020

Revision as of 19:19, 21 May 2020

Line 26:

== Related problems ==

The [[year 2038 problem]] is well known for another case where a 32-bit "long" on 32-bit platforms will lead into problems. Just like the large-file limitation it will get obsolete when systems move to 64-bit only. In the meantime a 64-bit timestamp was introduced. In the Win32 API it is visible in functions having a "64" suffix along the earlier "32" suffix. When large-file support was added to the Win32 API it has leadled to functions having an additional "i64" suffix which sometimes makes for four combinations.(findfirst32, findfirst64, findfirst32i64, findfirst64i32).<ref name="Microsoft_2019_CRT"/> By comparison the UNIX98 API introduces functions with a "64" suffix when "_LARGEFILE64_SOURCE" is used.

Related to the large-file API there is a limitation of block numbers for [[mass storage]] media. With a common size of 512 bytes per [[Block (data storage)|data block]] the barrier resulting from 32-bit numbers did occur later. When [[hard disk drive]]s reached a size of 2 terabyte (around 2010) the [[master boot record]] had to be replaced by the [[GUID Partition Table]] which uses 64-bit for the LBA numbers ([[logical block addressing|logical block address]]). On [[Unix-like]] operating systems it did also require to enlarge the [[inode]] numbers which are used in some functions (stat64, setrlimit64). The [[Linux kernel]] introduced that in 2001 leading to version 2.4 which was picked up by the glibc in that year.<ref name="lfs_2015"/> As the large-file support and large-disk support was introduced at the same time the [[GNU C Library]] exports 64-bit inode structures on 32-bit architectures at the same time when the Unix LFS API is activated in program code.<ref name="Linux_stat.h"/>