Message-ID: <7558@brl-tgr.ARPA>
Date: Sat, 19-Jan-85 14:04:43 EST
Article-I.D.: brl-tgr.7558
Posted: Sat Jan 19 14:04:43 1985
Date-Received: Wed, 23-Jan-85 07:56:49 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 5

Does anyone know an easy way to get file sizes in Kilobytes using TurboPascal?
If it would help I have a Kaypro computer.

		--Doug Good
-------

Message-ID: <7586@brl-tgr.ARPA>
Date: Mon, 21-Jan-85 03:51:09 EST
Article-I.D.: brl-tgr.7586
Posted: Mon Jan 21 03:51:09 1985
Date-Received: Wed, 23-Jan-85 19:16:59 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 41


 
 >   Does anyone know an easy way to get file sizes in Kilobytes using
 >   TurboPascal?  If it would help I have a Kaypro computer.
 
------------
In CP/M-80, the Turbo Pascal "filesize(filvar)" function will return the
number of records in the named file.  Each record consumes 128 bytes.  So,
the Kilobyte size is calculated by:  RECS x 128.  When the file is saved
in CP/M, file space is allocated in increments of 2K bytes.  The following
example will calculate the K's.
 
program find_k;
type
   filename = string[12];
var
   fname : filename;
   kfile : file;
   remain : boolean;
   i,recs,k,bytes : integer;
begin
   write('Enter the filename: ');
   readln(fname);
   for i:=1 to length(fname) do
      fname[i]:=upcase(fname[i]);
   assign(kfile,fname);
   reset(kfile);
   recs:=filesize(kfile);
   close(kfile);
   bytes:=recs*128;          { how many 128 byte records }
   k:=bytes div 1024;          { get the nearest k. oKay? }
   remain:=(bytes mod 1024)<>0;          { do I need another k? }
   if remain then k:=k+1;
   if (k=0) or odd(k) then k:=k+1;     { add another k for CP/M filesaves }
   writeln('That file is ',k,'K long')
end.


--Irwin Hom          {ihnp4, sdcsvax!bang}!crash!ihom
			   bang!crash!ihom@nosc
				bang!crash!ihom@ucsd

Message-ID: <5100006@iuvax.UUCP>
Date: Thu, 24-Jan-85 10:39:00 EST
Article-I.D.: iuvax.5100006
Posted: Thu Jan 24 10:39:00 1985
Date-Received: Sat, 26-Jan-85 06:28:44 EST
References: <7558@brl-tgr.UUCP>
Lines: 11
Nf-ID: #R:brl-tgr:-755800:iuvax:5100006:000:580
Nf-From: iuvax!apratt    Jan 24 10:39:00 1985


The submitted algorithm has some misleading information and at least one flaw
outright: Files CAN be empty, taking up zero K on the disk. The misleading part
is that not ALL CP/M systems allocate 2k at a time; mine (Osborne DD) allocates
only 1K.  This is nice since you waste at most 1023 bytes (as opposed to 2047
in the worst case of 2K clusters), but it is NOT nice in that reading a file
 > 16K causes a seek back to the directory to open another extent, whereas this
would only happen every 32K with 2K allocations. 
----
						-- Allan Pratt
					...ihnp4!inuxc!iuvax!apratt