From: rgrunsk AT ibm DOT net
Newsgroups: comp.os.msdos.djgpp
Subject: Re: fseek() bug?!?!
Date: 24 Mar 1997 00:05:00 GMT
Lines: 67
Message-ID: <5h4gfc$v3i$1@news-s01.ny.us.ibm.net>
References: <Pine DOT D-G DOT 3 DOT 91 DOT 970321112252 DOT 28140B-100000 AT dg1>
Reply-To: rgrunsk AT ibm DOT net
NNTP-Posting-Host: slip129-37-159-98.on.ca.ibm.net
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In <Pine DOT D-G DOT 3 DOT 91 DOT 970321112252 DOT 28140B-100000 AT dg1>, "art s. kagel IFMX x2697" <kagel AT dg1 DOT bloomberg DOT com> writes:
>
>Fseek() allows you to seek past the end of file and if you write to the 
>new location the file will be expanded to the new size either by filling 
>the intervening space with nulls or by allocating a sparse file as the OS 
>permits.  Obviously DOS does not support sparse files so the file is
>allocated any additional disk space, null or garbage filling (I'm not 
>sure, but it is easy enough to check) to the new size as soon as you 
>write to the new location if you do.
>
>Art S. Kagel, kagel AT ts1 DOT bloomberg DOT com
>
>On 19 Mar 1997, Christopher Keane wrote:
>
>> 
>> Hi all,
>> 
>> 
>> I've run into a strange problem which appears to be in fseek().
>> 
>> I have some code which has worked fine both under BC and Watcom 9.5, but 
>> doesn't in DJGPP 2.01.  Perhaps someone can tell me if I am making a bad 
>> assumption...
>> 
>> The code:
>> 
>> FILE *fin;
>> 
>> ...
>> 
>> while( ! feof(fin) )
>> {
>> 
>> ...
>> 
>> if( ... )
>> 	{
>> 	fread(.....)
>> 	...
>> 	}
>> else
>> 	{
>> 	fseek(....)
>> 	}
>> 
>> }
>> 
>> Obviously if the file fseeks past EOF, the program should dump out of the 
>> while.  It does this correctly when the fread hits the EOF....  However, 
>> it goes on for ever if it fseeks past the EOF.
>> 
>> So, I checked feof(fin) before and after the fseek....  On EOF, feof() 
>> before the fseek returns 64, so I know its past the end of the file.  
>> However, when I do a feof(fin) after the fseek() knowing full well that it 
>> is EOF, it returns 0!
>> 
>> It appears that fseek resets the error condition on EOF, causing this 
>> loop to fail.  I solved this with checking the feof() before the fseek() 
>> and breaking, but I don't understand why this should fail.

As a matter of interest, DOS just extends the file. Whatever is in the allocated
clusters remains. I have used this to turn the empty part of a drive to a file
to recover fragments of lost files. If you wan the extended file to be initialized
to some state. you will have to write the data yourself.


Rolf Grunsky