Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nrossi
From: nrossi@jarthur.Claremont.EDU (Nick Rossi)
Newsgroups: comp.sys.cbm
Subject: Re: Dis Defragmenter
Message-ID: <11298@jarthur.Claremont.EDU>
Date: 19 Mar 91 05:32:27 GMT
References: <31152@usc> <1991Mar19.041534.27398@bingvaxu.cc.binghamton.edu>
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 35

In article <1991Mar19.041534.27398@bingvaxu.cc.binghamton.edu> vu2416@bingvaxu.cc.binghamton.edu (vu2416) writes:

>     There was a thread going for a while about writing a defragmenter
>for Commodore disks.  I was seriously considering writing one (I've
>got code laying around that'll show the list of tracks and sectors in
>use by a particular file etc...) when I realized that the following
>process will work a lot faster:

>1.  Format a temporary disk
>2.  Copy the disk to defragment onto the temp disk
>3.  Format the defrag. disk
>4.  Use a file copier to copy all the files back onto the defrag.
>disk.

>DOS should write all the files in track / sector order.  My best idea
>was to use the REU as the temporary disk.  Maybe when I get my REU
>(it's in the mail) I'll look at the RAMDisk code to see if I can write
>a 'defragment' command.  If anyone's interested. :)

>Comments would be appreciated.

CBM DOS seems to write files in order of every ten sectors.  For example,
the first file on a disk would start at track 17 sector 0, and then save
to track 17 sector 10, t 17 s 1, t 17 s 11, t 17 s 2, etc.  Copying files
to a blank disk would produce this kind of ordering.  I don't know if this
makes for faster access or not.  Maybe the physical organization of the
disk works this way or something.  This is what I wanted to know about.
I normally just recopy files onto a blank disk when I am getting ready to
release stuff on disk.

>Gregg Riedel
>consp24@bingsuns.pod.binghamton.edu


Nick Rossi