Large-file support: Difference between revisions

Revision as of 04:15, 11 October 2018

Revision as of 04:24, 11 October 2018

Line 8:

While the limit was quite acceptable at a time when [[hard disk]]s 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.

In 1996, multiple vendors responded by forming an industry initiative known as the '''Large File Summit''', {{clarifyan span|(thusobvious "LFS"[[backronym]] can be considered to stand for eitherof "large-file supportLFS". orThe "Largesummit File Summit")|date=January 2015}},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.

Line 28:

==External links==

{{Reflist|refs=

<ref name="DRDOS_FAT+_R2">{{cite web|title=FAT+ draft revision 2|first1=Udo|last1=Kuhnt|first2=Luchezar|last2=Georgiev|first3=Jeremy|last3=Davis|date=2007|format=FATPLUS.TXT|edition=2|url=http://www.fdos.org/kernel/fatplus.txt|accessdate=2015-08-05}}{{cite web |url=http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.FATplus |title=Archived copy |accessdate=2012-11-12 |deadurl=yes |archiveurl=https://web.archive.org/web/20120320075317/http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.FATplus |archivedate=2012-03-20 |df= }}</ref>

}}

* {{ cite journal

Line 38:

}}

* {{cite journal

|authorfirst = Andreas |last = Jaeger

|date = 2005-02-15

|url = http://www.suse.de/~aj/linux_lfs.html

|title = Large File Support in Linux

|publisher = SuSE GmbH (now [[Novell, Inc.]])

|accessdate = 2006-09-10

}}

Line 50:

|url = http://www.sun.com/software/whitepapers/wp-largefiles/largefiles.pdf

|format = PDF |title = Large Files in Solaris: A White Paper

|publisher = [[Sun Microsystems, Inc.]]

|accessdate = 2006-09-10

|archiveurl = https://web.archive.org/web/20070228204423/http://www.sun.com/software/whitepapers/wp-largefiles/largefiles.pdf