Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!apple!dlyons
From: dlyons@Apple.COM (David Lyons)
Newsgroups: comp.sys.apple
Subject: Re: GS/OS file copying
Message-ID: <36623@apple.Apple.COM>
Date: 18 Nov 89 21:27:02 GMT
Article-I.D.: apple.36623
References: <8911181612.AA15334@apple.com> <36619@apple.Apple.COM>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 64

Josef Wankerl asks how to copy extended files under GS/OS, and Matt
Deatherage answers.  (By the way, today is Matt's birthday.  He's 17
years old today, if you use the right number base.)

Matt sez it wouldn't be a great idea to provide an option for copying
only one of the forks of an extended file.  But as long as the default
is always to copy both forks, it wouldn't hurt--there are times when
it comes in very handy.  (For example, when Apple ships APW interface
files that are extended with empty resource forks, and you want to
be able to read them under ProDOS 8.)


J> * How would I go about allocating memory for the copy? [...]

M>I would venture there's really no need to compact memory.  This could give
M>you lots of things you don't want, like kicking out the disk cache or at
M>least the purgeable blocks within it.  Just use _MaxBlock to find out what
M>the biggest chunk currently available is, subtract about 10K from it for
M>GS/OS overhead (if necessary) and use that.

There's no *best* way to decide how much memory to allocate in a case like
this.  First, Matt is correct that there's no need to CompactMem and try
your NewHandle call again, because compacting memory is one of the things
the Memory Manager does automatically before it gives up and gives you an
error from NewHandle.

(Note that CompactMem *doesn't* purge anything.  It just moves unlocked
not-fixed blocks to try to make MaxBlock bigger.)

In a lot of cases, using MaxBlock-xxK will work fine.  In the worst case,
MaxBlock is very small, and there are several megs of purgable memory
(dormant applications, cached images of menus, toolsets that aren't being
used any more) and more stuff that Out-of-memory-queue routines are
willing to dispose of for you (like GS/OS's cache).  (The cache is nice,
but it's not so nice that you want to force the user to do extra disk
swaps to copy a file!  The cache will dump itself *before* any purgable
memory blocks are purged.  It's very humble and self-sacrificing.)

I say try to allocate as much memory as you have a use for--if you can't
get that much, then ask for less.  You might try asking for X, then X/2,
X/3, X/4, etc--this will mean you can do it in the minimum number of
passes possible in the avilable memory.

To guarantee that there's a bit of memory around for the OS to play with,
you might want to allocate a (say) 10K block right before you allocate
the big block, and then dispose of the 10K block before the OS calls.

>[...] you can use GS/OS sessions to speed multiple file
>copies dramatically.  See GS/OS Reference for more details.

True (although if all the files are huge it won't be dramatic).
Using a session means none of the updated "system" blocks (bitmap and
directory blocks, for example) will be written out to disk until the
whole thing is done--this way they get written once at the end instead
of several times.  This can save a lot of disks seeks.
-- 

 --Dave Lyons, Apple Computer, Inc.          |   DAL Systems
   AppleLink--Apple Edition: DAVE.LYONS      |   P.O. Box 875
   America Online: Dave Lyons                |   Cupertino, CA 95015-0875
   GEnie: D.LYONS2 or DAVE.LYONS         CompuServe: 72177,3233
   Internet/BITNET:  dlyons@apple.com    UUCP:  ...!ames!apple!dlyons

   My opinions are my own, not Apple's.