From: Martin Stromberg 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: from "Eli Zaretskii" at Jan 13, 0 09:40:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit 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 Precedence: bulk > > 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