Bug#590513: apt-get fails on i386 with 20tb filesystem (statvfs (75: Value too large for defined data type))

[Guillem Jover <guillem@debian.org>]

Hi!

On Tue, 2010-07-27 at 13:29:07 +0200, Julian Andres Klode wrote:
> On Mo, 2010-07-26 at 15:23 -0700, David Bronaugh wrote:
> > When I try to install a package inside an i386 chroot on this machine
> > (which resides on a 20TB XFS filesystem), it fails to even get to
> > downloading the package with the following error messages:

> > It seems like this is likely a result of integer overflow in the data
> > structure that statvfs returns. Therefore, it would seem the path
> > forward is to use statvfs64().

> Fixed in bzr:
> 
> === modified file 'cmdline/apt-get.cc'
> --- cmdline/apt-get.cc	2010-07-05 09:34:35 +0000
> +++ cmdline/apt-get.cc	2010-07-27 11:21:03 +0000
> @@ -25,6 +25,9 @@
>     ##################################################################### */
>  									/*}}}*/
>  // Include Files							/*{{{*/
> +#define _LARGEFILE_SOURCE
> +#define _LARGEFILE64_SOURCE
> +
>  #include <apt-pkg/error.h>
>  #include <apt-pkg/cmndline.h>
>  #include <apt-pkg/init.h>
> @@ -63,6 +66,9 @@
>  #include <regex.h>
>  #include <sys/wait.h>
>  #include <sstream>
> +
> +#define statfs statfs64
> +#define statvfs statvfs64
>  									/*}}}*/
>  
>  #define RAMFS_MAGIC     0x858458f6

There's few problems with this patch. By defining _LARGEFILE_SOURCE,
the source is already requesting to the system to internally remap
statfs and statvfs to statfs64 and statvfs64. And in addition
_LARGEFILE64_SOURCE just makes the explicit 64 bit versions visible,
at which point the system was alredy transparently supporting large
files.

It unconditionally remaps itself the symbols to their 64 bit versions,
but they might not be available on the system, the correct way to check
for this is by using AC_SYS_LARGEFILE in configure.in.

It also does not fix the casted comparisons for some of the statfs and
statvfs members which will be now 64 bit wide on 32 bit systems.

As the API does not seem to expose any off_t type publicly, it seems
safe to enable large file support globally, if there's some exposed
API which could be affected, then just defining _LARGEFILE_SOURCE for
now at the top of this source and not doing the manual remapping would
do too. And the global switch can be done later on.

thanks,
guillem