Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3BC33F16.8E19850E@phekda.freeserve.co.uk>
Date:	Tue, 09 Oct 2001 19:16:54 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	Resend: DJGPP and files > 2GB
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

The bug in 'ls' a couple of months ago highlighted some problems with the
handling of files > 2GB in size. I've been looking at the Single Unix
Specification (SUSv2) and the Large File Summit:

SUSv2: http://www.opengroup.org/
LFS:   http://ftp.sas.com/standards/large.file/

An example of the problem is the handling of the st_size member of the
stat structure. st_size is an off_t. This means that the maximum size that
can be represented is 2GB - 1. Currently stat will return a large negative
number, since off_t is signed (which caused ls to output a bogus size). If
st_size cannot represent the file's size, stat is supposed to return -1
and set errno to EOVERFLOW.

I don't think the library's current behaviour is good - who knows what
effect silently returning bogus sizes for files >= 2GB will have?

There seem to be several ways of addressing the problem:

1. Grow off_t to a 64-bit type (i.e. signed long long). Clearly this will
break backward compatibility, but it may be the easiest solution for the
lazy programmer. ;)

2. Return EOVERFLOW when off_t can't represent the size. Since support for
files >= 2GB was added to DJGPP 2.04, we need to add functions that allow
people to use this support, otherwise there's no point having it. There
are two ways of doing this:

2a) The transitional API - *64 versions of current functions, e.g. stat64.
This and the traditional API can be used on the same descriptors.

2b) Large file functions and large off_t that are enabled when
_LARGEFILE_SOURCE is defined before including headers.

2a and 2b are not mutally exclusive.

2a doesn't appear to be used by Fileutils - perhaps the transition has
already occurred or people avoided the transitional API, because it was
clearly a temporary hack?

2b seems like the best solution, but how would we implement linking to
different versions of stat? Via #defines seems like the natural way, but
is this acceptable?

What do people think about adding LFS support to DJGPP?

I think we should add the checking for overflowing of off_t right now. I'm
willing to look at this and code it up. 2b may take longer.

Thanks, bye, Rich

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/

- Raw text -