Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!xadmx!microsoft!richardw@uunet.uu.net
From: microsoft!richardw@uunet.uu.net
Newsgroups: comp.lang.pascal
Subject: Re: Read/WriteBlock procedures in TP 5.x
Message-ID: <21448@adm.BRL.MIL>
Date: 15 Nov 89 12:42:32 GMT
Sender: news@adm.BRL.MIL
Lines: 30


|>From: "Predrag S. Bundalo" <uunet!iitmax.iit.edu!bundalo>
|Subject: Re: Read/WriteBlock procedures in TP 5.x
|
|        I've received numerous explanations ( thanks ! ), but not
|        a one solution.  Now I know about the way DOS allocates
|        space for files, and clusters, and all that, but I don't
|        know how to go about overcoming the problem.  Would truncating
|        the file to the right size deallocate the extra space DOS
|        conveniently allocated for me?  How does DOS's "copy" program
|        work?  I mean how does IT overcome the allocation problem?

There isn't any way to get around the problem with a FAT based file system.
The cluster allocation goes on below the layer dealing with file sizes.  The
space allocated is always going to be (filesize div clustersize) + 1 clusters
if filesize mod clustersize <> 0.  COPY doesn't get around the problem, either.

|        I've also noticed that it (dos's copy program) reads in quite
|        a bit before writing.  Anyone know how much?  Is this documented
|        in the DOS Technical Reference manual?

Program specifics are generally not listed in the DOS TechRef.  However, the
most you can read in with a single DOS call is 64K-1 bytes, I would hazard a
guess that that is the size that COPY is using.


-Richard Ward
uunet!microsoft!richardw
microsoft!richardw@uunet.uu.net
The above has no relation to Microsoft corporate policy.