Content deleted Content added
m Voidxor moved page Large file support to Large-file support: Compound adjective |
m Copy edit. →See also: Alphabetize per MOS:SEEALSO. |
||
Line 1:
{{More footnotes|date=March 2009}}
'''Large
==Details==
Line 7 ⟶ 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''' {{clarify span|(thus "LFS" can be considered to stand for either "large
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
* 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
* 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.)
Line 19 ⟶ 20:
==See also==
* [[File size]]▼
* [[2 GB limit]]
▲* [[File size]]
* [[Long filename support]] (LFN)
* [[Year 2038 problem]]
▲* [[Comparison of text editors#Extra features|Comparison of large file support in text editors]]
==External links==
Line 48 ⟶ 49:
|date = March 1996
|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
|
|
}}
| |||