Large File Support

Goal description

Fix all applications to remove arbitrary file size limits (generally 2GB+), or other large counts such as inode values (see 760985 for an example). This implies not slurping or mmap(2)ing large files into memory (as that might exceed the address space), using correct 64-bit types (f.ex. off_t instead of ssize_t, uint64_t instead of int, etc), using the correct 64-bit variants of types such as off_t, fpos_t, ino_t, rlim_t, blkcnt_t, fsblkcnt_t, fsfilcnt_t and any derived structs that have members with those types, using the correct 64-bit variants of system functions (such as open(2) or stat(2)).

Using the correct system interfaces can be done by defining the preprocessor macro as _FILE_OFFSET_BITS=64. For projects using autoconf, by adding the AC_SYS_LARGEFILE m4 macro. Otherwise the dpkg-buildflags build feature abi=+lfs can be used to set the correct values in the build flags. Note though, that getconf LFS_CFLAGS must not be used, as it does not support cross-building. Using _FILE_OFFSET_BITS should require no system function renames (for example from open(2) to open64(2)).

lintian contains a test that can help identify packages that are not LFS-safe, but it cannot guarantee packages that do not emit the tag are LFS-safe, as they might use inappropriate types or code that might incur in OOM conditions, file truncation, or overwrites.

Note also that enabling LFS for shared objects (shared libraries or plugin interfaces) might imply an ABI break, so this should be evaluated carefully. If there is ABI breakage then this can be queued for the next SONAME bump, or otherwise it needs a transition by keeping the current SONAME but the package name needs to be renamed, and the new one conflict with the old one, which can be rather disruptive for upgrades.

Current status

How to help