From:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id:	<200001130902.KAA13971@spica-144.lu.erisoft.se>
Subject:	Re: _lleek
To:	djgpp-workers AT delorie DOT com
Date:	Thu, 13 Jan 100 10:02:54 +0100 (MET)
In-Reply-To:	<Pine.SUN.3.91.1000113093949.9693S-100000@is> from "Eli Zaretskii" at Jan 13, 0 09:40:06 am
X-Mailer:	ELM [version 2.4 PL24]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> > This requires an extra call to the INT21 function for the SEEK_CUR
> > case.
> 
> I don't see anything wrong with this, but could you please reiterate
> the exact nature of the problem?  It's a long time since we discussed
> this.
> 
> Didn't you tell at one point that the maximum file size on FAT32 is
> less than 2^32, and that this could help us solve the problems?

Max file size is 2^32-2. (2^32 == size 0 and 2^32-1 == failure).

Hmm, I don't recall that this will help us solve our problems. But any
ideas are welcome!

The problem is that the INT21 call registers used for offset (input
and output) is totally only 32 bits, so we have this mapping: 
register contents -> offset
0			0
.			.
.			.
.			.
2^32-2			2^32-2
2^32-1			-1 (failure)

So my tests showed calling lseek(fd, -2, SEEK_SET) would result in the
file growing to maxsize (as if lseek(fd, 2^32-2 , SEEK_SET) was
called). Please try this and verify my findings, if possible.

Meanwhile I have discovered that _llseek(fd, offset, SEEK_END) will
also need an extra call to make my (latest) idea work.
 

This Mortal Coil, Blood,

							MartinS

- Raw text -