Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3D0C5970.80BB0B9C@phekda.freeserve.co.uk>
Date:	Sun, 16 Jun 2002 10:25:04 +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:	<200206152059 DOT g5FKxue00121 AT speedy DOT ludd DOT luth DOT se>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Martin Str|mberg wrote:
> 
> According to Richard Dawe:
> > > Yes. So...?
> >
> > A negative absolute offset into a file does not make sense.
> 
> There are no negative offsets into any file. And if you use llseek()
> you won't (shouldn't) have a negative offset.

So how do you store +4GB - 2B in an off_t (long) _as a positive number_?

I think we're arguing at cross-purposes. Let's try this. I believe we can
currently do this:

    lseek(fd, 0, SEEK_SET);
    lseek(fd, 2GB - 1B, SEEK_CUR);
    lseek(fd, 2GB - 1B, SEEK_CUR);

So now the file position is at 4GB - 2B. But lseek can't return the offset as
a positive number in the final call. 2GB - 1B is the maximum offset we can
represent in the positive portion of a long. 'ls' (IIRC which program) from
Fileutils has already been bitten by this bug.

The points of LFS are, I believe:

* 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.

* It provides a way of extending the size of off_t, to allow you to access
larger files. You gain access to these files by #define _LARGEFILE_SOURCE,
before including any of the system headers.

There's also the transitional interface, that you can use at any time. This
interface comprises the *64 functions, e.g.: lseek64 which is identical to
llseek.

Bye, Rich =]

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

- Raw text -