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 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> 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: > > > 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/ ]