Date: Wed, 8 Aug 2001 14:18:32 -0700 (PDT)
From: Paul Eggert <eggert AT twinsun DOT com>
Message-Id: <200108082118.f78LIWJ01104@shade.twinsun.com>
To: eliz AT is DOT elta DOT co DOT il
CC: rich AT phekda DOT freeserve DOT co DOT uk, djgpp-workers AT delorie DOT com
In-reply-to: <7458-Wed08Aug2001221720+0300-eliz@is.elta.co.il>
Subject: Re: GNU ls bug on DJGPP with large files
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010808174034 DOT 27069A-100000 AT is> <200108081737 DOT f78HbTf00873 AT shade DOT twinsun DOT com> <7458-Wed08Aug2001221720+0300-eliz AT is DOT elta DOT co DOT il>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Wed, 08 Aug 2001 22:17:21 +0300
> From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
> 
> > For example, its emulation of the 'stat'
> > system call should return -1 on files larger than 2GB, and should set
> > errno to EOVERFLOW in that case.
> 
> Why?  `stat' does support files up to 4GB - 2bytes; it has no reason
> to fail.

No, it doesn't support those files, because it doesn't represent their
sizes correctly.  For example, if the file size is 2147483650 bytes,
it returns a st_size value of -2147483646.  This isn't correct.

A similar situation arises in GNU/Linux, Solaris, and other hosts.
For example, on my Solaris 8 host:

     $ cat >t.c <<'EOF'
     #include <stdio.h>
     #include <sys/stat.h>
     int main () {
       struct stat st;
       if (fstat (0, &st) != 0)
	 perror ("fstat");
     }
     EOF
     $ gcc t.c
     $ echo x | dd bs=1024k oseek=2048 >large
     0+1 records in
     0+1 records out
     $ ls -l large
     -rw-rw-r--   1 eggert   eggert   2147483650 Aug  8 14:00 large
     $ ./a.out <large
     fstat: Value too large for defined data type

Here we also have a case where the filesystem and some apps can
support a file whose size is 2147483650, but in the default Solaris 8
compilation model (which is analogous to DGJPP's only compilation
model in that off_t is 32 bits), fstat cannot represent the resulting
size correctly.  And the default-model Solaris 8 fstat does the right
thing: it returns -1 with errno == EOVERFLOW.

> The latest released version doesn't even support more than 2GB

In that case, please consider my message to be an early warning of the
problem.  When you add support for files in the 2GB - 4GB range,
please increase off_t to be a type wider than 32 bits; or please
modify all the off_t-related system calls to return EOVERFLOW for
offsets greater than 2**31-1.  I prefer the former solution, but
either solution will do, and either will be more reliable and robust
than modifying all the GNU applications to deal with this gratuitous
incompatibility with POSIX.