Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!milne
From: milne@ics.uci.edu (Alastair Milne)
Newsgroups: comp.lang.pascal
Subject: Re: Blockread/write problem
Message-ID: <26DE0F04.26212@ics.uci.edu>
Date: 31 Aug 90 07:17:24 GMT
References: <24316@adm.BRL.MIL> <1990Aug29.123053.17412@ux1.cso.uiuc.edu>
Organization: UC Irvine Department of ICS
Lines: 54

In <1990Aug29.123053.17412@ux1.cso.uiuc.edu> dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) writes:

>>1. When I run this program, I don't get the whole file copied (I miss several
>>   bytes).
>>   FILE.1  TEMP   missing bytes:
>>   7056    7040    16
>>   6899    6784    115
>>   6296    6272    24
>>   3040    2944    96

>Notice that all the TEMP sizes are multiples of 128, the default record size.
>Try reset(fil1,1) instead.

    Doing an entire BlockRead for a single byte seems a waste of the routine,
    and probably invites a lot of overhead.  If you want to do single-character
    I/O, skip BlockIO altogether and just use FILE OF BYTE, with plain READs.  
    May even be faster than BlockIO.

>>2. When I reset a read-only file, why does TurboPascal then say that it is
>>   impossible to open the file<>
>My guess is that this is an 'undocumented feature' (aka bug).

    I'm not quite sure what sequence you're following, but the reason I 
    am posting this as a follow-up, rather than as a private reply, 
    is because of the very nasty behaviour of Turbo Pascal's IOResult
    in cases like this, which I think should be as widely known as possible.

    The loop you showed in your original code does no IOResult checks.
    This could get you into real trouble because:
       
	If IOResult goes non-zero, all subsequent I/O activity on that channel
	-- or possibly on all channels -- is *blocked* until IOResult is
	cleared by being called.  (Whether losing IOResult's report as a 
	side-effect of calling it is desirable is yet another issue.)

    I suspect you are not getting the whole file copied because BlockRead's
    last call causes a non-zero IOResult because of not being able to read a
    full 128-byte block.  This would keep BlockWrite from doing any further
    I/O, so the final chunk from the source doesn't get written into the
    target.  In fact, if you actually had to close and lock the new file 
    to make it permanent in the directory, you probably wouldn't even be
    seeing it created.

    As I may have mentioned in previous postings, I consider this organisation
    of Turbo Pascal's I/O system a serious design error, and I very much hope 
    that Borland will reconsider it for future releases.

    Try putting in the IOResult checks, after both BlockIO calls.  I suspect
    it will clear up this behaviour; and even if it doesn't, it will still
    make your copy more robust and friendly.

    Good luck,

    Alastair Milne