[comp.lang.pascal] Blockread/write problem

S89405079%HSEPM1.HSE.NL@vm1.nodak.edu (08/29/90)

Hi,

I have a little problems with the use of blockread/blockwrite in TurboPascal.

========================================================================
The program:

program    xcopy;
uses       dos;
const      recsize=$FF;
           busize=120;
var        fil1,fil2:file;                              {The file to be copied}
           buffer:array[1..recsize,1..bufsize] of byte; {For blockread/write}
           recsread:integer;

begin
  assign(fil1,'FILE.1');reset(fil1);    {Sourcefile}
  assign(fil2,'TEMP');rewrite(fil2);    {Targetfile}
  repeat
    blockread(fil1,buffer,bufsize,recsread);
    blockwrite(fil2,buffer,recsread);
    writeln(recsread:5,' blocks written.');
  until recsread=0;
  close(fil1);close(fil2);
end.

=========================================================================

My problems:

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

   Does anybody have the solution for this *irritating* problem <>

2. When I reset a read-only file, why does TurboPascal then say that it is
   impossible to open the file<>


A lot of tanx to everybody with any solutions...

Edwin Groothuis
S89405079@hsepm1.hse.nl

dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) (08/29/90)

S89405079%HSEPM1.HSE.NL@vm1.nodak.edu 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
>
>   Does anybody have the solution for this *irritating* problem <>

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

>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).

Daniel Lewart
d-lewart@uiuc.edu

rio@tension.me.utoronto.ca (Oscar del Rio) (08/30/90)

In article <1990Aug29.123053.17412@ux1.cso.uiuc.edu> dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) writes:
>
>S89405079%HSEPM1.HSE.NL@vm1.nodak.edu writes:
>
>>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).
>
>Daniel Lewart

No. It is not a bug and it is documented in the manuals.
By default, when you open a file (with reset) TP tries to open it as a
Read/Write file, i.e., you can read it and you can write to it.
Obviously, if the file is a read-only one, TP reports the error.

There is a variable called FileMode that TP checks when opening a file.
If you know that you will open the file only for reading, you can set
FileMode:=0  before trying to open it. By default, FileMode=2 (read/write).

Oscar.

lowey@herald.usask.ca (Kevin Lowey) (08/30/90)

From article <1990Aug29.123053.17412@ux1.cso.uiuc.edu>, by dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart):
> S89405079%HSEPM1.HSE.NL@vm1.nodak.edu writes:
> 
>>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).

This "bug" is "undocumented" on page 114 of the Turbo Pascal 5.0 Reference
Guide under the "FILEMODE" variable:

=== Beginning of quote ===

The FILEMODE variable defined by the SYSTEM unit determines the access code
to pass to DOS when typed and untyped files (not text files) are opened using
the RESET procedure.

The default FILEMODE is 2, which allows both reading and writing.  Assigning
another value to FILEMODE causes all subsequent RESETS to use that mode.

The range of valid FILEMODE values depends on the version of DOS in use.
However, for all versions, the following modes are defined:

  0: READ ONLY
  1: WRITE ONLY
  2: READ/WRITE

DOS version 3.x defines additional modes, which are primarily concerned with
file-sharing on networks. (For further details on these, please refer to your
DOS Programmer's reference manual.)

NOTE: New files created using REWRITE are always opened in READ/WRITE mode,
corresponding to FILEMODE = 2.

=== End of quote ===


Also, in the section on DOS file errors, on page 468:

=== Start of quote ===

5 File Access Denied.
- Reported by RESET or APPEND if FILEMODE allows writing and the name
assigned to the file variable specifies a directory or a read-only file.

=== End of quote ===


Funny what you find when you look the error messages up in the manual #8-)

- Kevin Lowey (LOWEY@SASK.USASK.CA LOWEY@SASK.BITNET)

mead@uxh.cso.uiuc.edu (08/30/90)

/* Written  7:09 am  Aug 29, 1990 by S89405079%HSEPM1@vm1.nodak.edu in uxh.cso.uiuc.edu:comp.lang.pascal */
/* ---------- "Blockread/write problem" ---------- */
Hi,

I have a little problems with the use of blockread/blockwrite in TurboPascal.

========================================================================
The program:

program    xcopy;
uses       dos;
const      recsize=$FF;
           busize=120;
var        fil1,fil2:file;                              {The file to be copied}
           buffer:array[1..recsize,1..bufsize] of byte; {For blockread/write}
           recsread:integer;

begin
  assign(fil1,'FILE.1');reset(fil1);    {Sourcefile}
  assign(fil2,'TEMP');rewrite(fil2);    {Targetfile}
  repeat
    blockread(fil1,buffer,bufsize,recsread);
    blockwrite(fil2,buffer,recsread);
    writeln(recsread:5,' blocks written.');
  until recsread=0;
  close(fil1);close(fil2);
end.

=========================================================================

My problems:

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

   Does anybody have the solution for this *irritating* problem <>

2. When I reset a read-only file, why does TurboPascal then say that it is
   impossible to open the file<>


A lot of tanx to everybody with any solutions...

Edwin Groothuis
S89405079@hsepm1.hse.nl
/* End of text from uxh.cso.uiuc.edu:comp.lang.pascal */

milne@ics.uci.edu (Alastair Milne) (08/31/90)

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

billaud@geocub.greco-prog.fr (Michel Billaud) (08/31/90)

In article <24316@adm.BRL.MIL> S89405079%HSEPM1.HSE.NL@vm1.nodak.edu writes:
>I have a little problems with the use of blockread/blockwrite in TurboPascal.
>program    xcopy;

>const      recsize=$FF;
		    ^^^ shouldn't it be 128 ? 
(cf. p115 in doc. french version of TP3.0)



You're welcome !

M.Billaud