Matches in DBpedia 2016-04 for { <http://wikidata.dbpedia.org/resource/Q6489130> ?p ?o }
Showing triples 1 to 38 of
38
with 100 triples per page.
- Q6489130 subject Q7145958.
- Q6489130 abstract "Large file support, often abbreviated as LFS, is the term frequently applied to the ability to create files larger than either 2 GB or 4 GB on 32-bit operating systems.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.In 1996, multiple vendors responded by forming an industry initiative known as the Large File Summit (thus "LFS" can be considered to stand for either "large file support" or "Large File Summit"), tasked to define a standardized way to switch to 64-bit numbers to represent file sizes.Merely ensuring the sizes were treated as unsigned numbers would only increase the limit from 2 GB−1 to 4 GB−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 GB−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 GB−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 GB−1; one has to use NTFS instead. (Some alternative file system implementations support an extension named FAT32+, which supports file sizes up to 256 GB−1 in a mostly backward compatible way, but this extension is not supported in mainstream operating systems so far.) 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 fseek and ftell operate 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 fseeko and ftello in POSIX. On Windows machines, under Visual C++, functions _fseeki64 and _ftelli64 are used.) 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.↑".
- Q6489130 wikiPageExternalLink lfs.html.
- Q6489130 wikiPageExternalLink largefiles.pdf.
- Q6489130 wikiPageExternalLink linux_lfs.html.
- Q6489130 wikiPageWikiLink Q1146367.
- Q6489130 wikiPageWikiLink Q1193832.
- Q6489130 wikiPageWikiLink Q12503.
- Q6489130 wikiPageWikiLink Q131765.
- Q6489130 wikiPageWikiLink Q1406.
- Q6489130 wikiPageWikiLink Q15777.
- Q6489130 wikiPageWikiLink Q165194.
- Q6489130 wikiPageWikiLink Q166142.
- Q6489130 wikiPageWikiLink Q170434.
- Q6489130 wikiPageWikiLink Q174989.
- Q6489130 wikiPageWikiLink Q183205.
- Q6489130 wikiPageWikiLink Q190167.
- Q6489130 wikiPageWikiLink Q225147.
- Q6489130 wikiPageWikiLink Q252132.
- Q6489130 wikiPageWikiLink Q300914.
- Q6489130 wikiPageWikiLink Q4439.
- Q6489130 wikiPageWikiLink Q459405.
- Q6489130 wikiPageWikiLink Q4633325.
- Q6489130 wikiPageWikiLink Q47506.
- Q6489130 wikiPageWikiLink Q7145958.
- Q6489130 wikiPageWikiLink Q7512911.
- Q6489130 wikiPageWikiLink Q778586.
- Q6489130 wikiPageWikiLink Q79738.
- Q6489130 wikiPageWikiLink Q827237.
- Q6489130 wikiPageWikiLink Q82753.
- Q6489130 wikiPageWikiLink Q83370.
- Q6489130 wikiPageWikiLink Q844605.
- Q6489130 wikiPageWikiLink Q8513.
- Q6489130 wikiPageWikiLink Q851989.
- Q6489130 wikiPageWikiLink Q856846.
- Q6489130 wikiPageWikiLink Q9135.
- Q6489130 comment "Large file support, often abbreviated as LFS, is the term frequently applied to the ability to create files larger than either 2 GB or 4 GB on 32-bit operating systems.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).".
- Q6489130 label "Large file support".