Large-file support: Difference between revisions

Revision as of 04:24, 11 October 2018

Revision as of 04:33, 11 October 2018

Line 10:

In 1996, multiple vendors responded by forming an industry initiative known as the '''Large File Summit''', an obvious [[backronym]] of "LFS". The summit was tasked to define a standardized way to switch to [[64-bit]] numbers to represent file sizes.

Merely ensuring the sizes were treated as [[signedness|unsigned]] numbers would only increase the limit from 2 GiB−1 to 4 GiB−1, which would have been only a stopgap measure given the explosive growth in data storage. Nevertheless, [[Windows 95B]] / [[DOS]] 7.10 introduced an API extension (most notably an extended file open call) to access files up to the full 4 GiB−1 bytes possible on [[FAT16B]] and [[FAT32]] volumes. Applications not aware of this extension continue to use the traditional file open call and were thereby still limited to a maximum of 2 GiB−1 bytes for [[backward compatibility]] reasons.

This switch caused deployment issues and required design modifications, the consequences of which can still be seen:

* The change to 64-bit file sizes frequently required incompatible changes to file system layout, which meant that large-file support sometimes necessitated a file system change. For example, [[Microsoft Windows]]' FAT32 file system does not support files larger than 4 GiB−1; one has to use [[NTFS]] instead. (Some alternative file system implementations support an extension named [[FAT32+]], which supports file sizes up to 256 GiB−1 in a mostly backward compatible way,<ref name="DRDOS_FAT+_R2"/> but this extension is not supported in mainstream operating systems so far.)

* To support binary [[Backward compatibility|compatibility]] with old [[Application software|applications]], operating system [[Application programming interface|interfaces]] had to retain their use of 32-bit file sizes and new interfaces had to be designed specifically for large-file support.

* To support writing [[porting|portable]] code that makes use of LFS where possible, [[C standard library]] authors devised mechanisms that, depending on [[C preprocessor|preprocessor]] constants, transparently redefined the functions to the 64-bit large -file aware ones.

* Many old interfaces, especially [[C (programming language)|C]]-based ones, explicitly specified argument types in a way that did not allow straightforward or transparent transition to 64-bit types. For example, the C functions <code>[[fseek]]</code> and <code>ftell</code> operate on file positions of type <code>long int</code>, which is typically 32 bits wide on 32-bit platforms, and cannot be made larger without sacrificing backward compatibility. (This was resolved by introducing new functions <code>fseeko</code> and <code>ftello</code> in POSIX. On Windows machines, under Visual C++, functions <code>_fseeki64</code> and <code>_ftelli64</code> are used.)

* In addition to all of the efforts listed above, all applications had to be [[Compiler|recompiled]] to become LFS-aware. The resulting [[Executable|binaries]] were typically not running on older releases of the same operating system. This was, and to some extent still remains, a problem for some application vendors.

==See also==