Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!spdcc!ima!cfisun!stardent!jmuller
From: jmuller@Stardent.COM (Jim Muller)
Newsgroups: comp.sys.apple2
Subject: Re: two questions...
Message-ID: <1990Dec6.194717.3054@Stardent.COM>
Date: 6 Dec 90 19:47:17 GMT
References: <1990Nov5.141216.28524@mintaka.lcs.mit.edu> <4673@tellab5.tellabs.com>
Organization: Stardent Computer, Newton MA
Lines: 31

In <4673@tellab5.tellabs.com> toth@tellabs.com (Joseph G. Toth) writes:
>In <1990Nov5.141216.28524@mintaka.lcs.mit.edu>, dcw@lcs.mit.edu
   (David C. Whitney) writes:
>...a special option
>
>   close ( file_id, crunch );
>
>where the crunch option causes a file system compression.

And then in <24019.apple.net@pro-avalon>
   jeff@pro-avalon.cts.com (Jeff Jungblut) writes:
>I don't remember the crunch option.  Was this new in 1.3?

No, it was not new in 1.3.  In fact, it wasn't even new in 1.2.
It is (I believe) a "standard" UCSD-Pascal option, and it doesn't
cause a file system compression.  The crunch option for CLOSE causes
the file to be marked EOF immediately after the point of last access
rather than the end of that disk block.  Normally when a file is
extended in place or created, the system grabs the next disk block.
If you do a normal close, the file will contain whatever was on the
disk through that block.  If it is an edited text file, this won't
matter, since text files are managed by the system via a 2-block
header.  For a data file or a text file that is created by a program,
it may not matter either as long as subsequent reads attempt to read
only what was originally written.  But if you were to edit a text file
that a program, not the editor, had created, you would pick up a lot
of garbage at the end of the file.  Thr crunch option prevents that.
I suspect that J.G.T. mistook this for the Filer command K(runch),
which does do a file-system compression.
-- 
 - Jim Muller