[comp.sys.apple2] writing many small files to disk... a quick way?

Andy Tefft <ART100@psuvm.psu.edu> (03/28/91)

I have recently had need to copy several (a few hundred) small
(1 or 3 block) files to 5.25" disks (from ram disk or 3.5").
I have been using copyII+ for this function but it is unbelievably
slow (about a half hour for 80 of these files).

One of the problems involved here is that these files are to go
in subdirectories. Copy II+ seems to like to screw around with
the directory entries much too much (don't know if this is an
MLI artifact or not). The directories, containing 80+ files,
tend to grow slowly to 6-8 blocks each, and unfortunately
they are fragmented across the disk (because by the time the directory
needs extended, another 3 tracks or so have been allocated to files
and there is no room for a new directory block next to the old ones).

Anyway, the net result is my poor 5.25" drive constantly tracking
(seems the whole subdirectory keeps getting scanned for each file
to be written... whoosh whoosh whoosh (pause) whoshwhooshwhoosh
(pause) whoosh whoosh whooshwhoosh (etc.)) and each 3 block file
taking about 10 seconds to copy (access time from /ram is negligible,
so it's all write activity that is so slow).

So I guess I'm asking if anyone knows of a method that will work
on a non-gs machine for quickly copying scads of small files between
dissimilar devices.

It would be really neat if they could all be written in a big
bunch and the directory updated all at once.

svetozar@pnet51.orb.mn.org (Eric C. Anderson) (03/30/91)

Hi.  Thing number one:  the reason your directories slowly get bigger as you
place files in 'em is because each 512-byte block of a directory file contains
room for 13 file entries.  When you attempt to place a file inside a directory
which has no room for the new file entry, ProDOS allocates a new block for the
directory file (a ProDOS directory is a doubly-linked list, if you're
interested).  Now, the reason this new directory block is separated from the
directory file's previously-allocated blocks is because you have been busily
copying files to the disk.  The block you would _like_ to be allocated, i.e.
the one which is only one block away from the directory's previously-allocated
blocks, has already been allocated for one of those files you were copying. 
Oh well.  This is one of the reasons for the existence of disk-optimizing
programs.  There are several such programs for the Apple IIgs (heck, even I
wrote one...), but I am not aware of any for the eight-bits.  Perhaps a
better-informed person out there will be able to direct you to such a program.

Thing number two: yes, you're right - Copy II+ is unconscionably slow for
copying files.  There is a program called "Cat Doctor" (part of Glen Bredon's
ProSel package) which accomplishes this task with greater efficiency.  It's
faster, too.  :)

Anyway, sorry for being long-winded; hope that helps a little.

Bye.

UUCP: {amdahl!bungia, crash}!orbit!pnet51!svetozar
ARPA: crash!orbit!pnet51!svetozar@nosc.mil
INET: svetozar@pnet51.orb.mn.org