Large file support
|This article is being considered for deletion in accordance with Wikipedia's deletion policy.
Please share your thoughts on the matter at this article's entry on the Articles for deletion page.
Feel free to edit the article, but the article must not be blanked, and this notice must not be removed, until the discussion is closed. For more information, particularly on merging or moving the article during the discussion, read the guide to deletion.
||This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (March 2009)|
Traditionally, many operating systems and their underlying file system implementations used 32-bit integers to represent file sizes and positions. Consequently, no file could be larger than 232 − 1 bytes (4 GB − 1). In many implementations, the problem was exacerbated by treating the sizes as signed numbers, which further lowered the limit to 231 − 1 bytes (2 GB − 1). Files that were too large for 32-bit operating systems to handle came to be known as large files.
While the limit was quite acceptable at a time when hard disks were smaller, the general increase in storage capacity combined with increased server and desktop file usage, especially for database and multimedia files, led to intense pressure for OS vendors to remove the limitation.
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 GB − 1; one has to use NTFS instead.
- To support binary compatibility with old applications, operating system 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 portable code that makes use of LFS where possible, C standard library authors devised mechanisms that, depending on preprocessor constants, transparently redefined the functions to the 64-bit large file aware ones.
- Many old interfaces, especially 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
ftelloperate on file positions of type
long int, 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
ftelloin POSIX. On Windows machines, under Visual C++, functions
- In addition to all of the efforts listed above, all applications had to be recompiled to become LFS-aware. The resulting 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.
- "Adding Large File Support to the Single UNIX Specification". X/Open Base Working Group. 1996-08-14. Retrieved 2006-09-10.
- Andreas Jaeger (2005-02-15). "Large File Support in Linux". SuSE GmbH (now Novell, Inc.). Retrieved 2006-09-10.
- Solaris OS group (March 1996). "Large Files in Solaris: A White Paper" (PDF). Sun Microsystems, Inc. Retrieved 2006-09-10.