Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!udel!new
From: new@udel.edu (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: More dos questions
Message-ID: <3579@nigel.udel.EDU>
Date: 7 Nov 89 18:53:14 GMT
References: <5599@ucdavis.ucdavis.edu> <8181@cbmvax.UUCP> <4952@freja.diku.dk>
Sender: usenet@udel.EDU
Reply-To: new@udel.edu (Darren New)
Organization: University of Delaware
Lines: 20

In article <4952@freja.diku.dk> thomas@rimfaxe.diku.dk (Thomas Nikolajsen) writes:
>This answer indicates that:
>  (X) all data blocks in a file, but the last, shall have the same length.
>Especially this shall be the case for OSF (the old file system), but there
>each data block does have a long word containing the length of the data in the
>block, this seems quite stupid if it is only really used in the last one. If it
>is only for the redundancy with the total number of bytes in the files, stored
>in the file header block, then it seems to be a waisted long word per data
>block, it could be done cheaper.

Actually, it is used for (1) redundancy and (2) efficiency.  If you manually
patch an OFS disk files' last block to have more or fewer bytes, that many
bytes will get read by a sequential read (ie, read to eof). I did this once trying
to cut the ctrl-Zs from a file and it just wouldn't work.  I think the general
answer is to not screw around with the bytecounts except thru the filesystem.

Since the original question was about copying files, these calculations should
work for the destination file even if the source file has strange numbers
in the blocks.  If the header block does not match the data blocks, something
is wrong anyway; how you count the blocks is problematical. -- Darren