Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3D0C8D97.DBE78079@phekda.freeserve.co.uk>
Date: Sun, 16 Jun 2002 14:07:35 +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 AT delorie DOT com
Subject: Re: DJGPP and the Large File Summit (LFS)
References: <200206161014 DOT g5GAE6c04679 AT speedy DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Martin Str|mberg wrote:
> 
> According to Richard Dawe:
[snip]
> > represent in the positive portion of a long. 'ls' (IIRC which program)
> > from Fileutils has already been bitten by this bug.
> 
> Yes. And I think the solution is llseek(). At least that was my idea
> when I wrote it.

Unfortunately it's not just lseek that can't cope properly with files bigger
than 2GB. The problem with 'ls' was that stat returns the file size member
which is a negative number (> 2GB - 1B). So *stat need to be fixed too.

See a mail to djgpp-workers by Paul Eggert "Re: GNU ls bug on DJGPP with large
files". This is dated Wed, 8 Aug 2001 10:37:29 -0700 (PDT) in my mail archive.

> > * It won't let you seek beyond the maximum offset [that you can represent
> > in the positive portion of off_t]. This is where the file manipulation
> > files return -1 and errno == EOVERFLOW.
> 
> Then change lseek() to guard for this. (Use llseek() and some math to
> check for "overflow".)
> 
> Or perhaps this is what you intend to do?

Yes, that's one of the functions that needs fixing.

LFS requires that file functions return -1 and EOVERFLOW, if they would go
past the maximum offset representable by an off_t. One benefit of this is to
catch problems in programs that have not been written with the expectation
that the offset could be negative. (I think that's a reasonable expectation!)
For instance, consider the following code:

    int some_file_descriptor;
    off_t o;

    ...
    o = lseek(some_file_descriptor, 1234, SEEK_CUR);
    if (o < 0)
        perror("bleurgh"), exit(EXIT_FAILURE);
    ...

Is that code valid? It looks reasonable, if you expect file offsets to always
be positive. But it will break with DJGPP CVS & large files. If you look at
the actual definition of lseek in the Austin draft 7, it does say that only a
return value of -1 indicates an error. So the code, though it looks
reasonable, is broken.

Sure, you can work around the "negative offsets are really postive offsets >=
2GB" problem. But you have to patch every single application that might hit
this problem. Isn't it more sensible to support a larger off_t [in a
backwardly- and binarily-compatible way], to avoid having to hack every
program? With LFS support, you just define _LARGEFILE_SOURCE and recompile.

Bye, Rich =]

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