Evening, all.  I've tried a few of the things you've suggested.  Have the
following to report.
When I tried defragmenting in Safe mode it only took two hours - so a vast
improvement on the all-nighters I'd had in Normal mode.
Next time I tried again in Normal mode - back to the long period defrag.
Then I tried in Normal again, but used Ctrl-Alt-Delete to see what else was
running, and here's the list it gave me:  Explorer, Msnmsgr, Avgemc, Avgcc,
Usbmonit, Qttask, Loadqm, Systray.
Can any of you experts tell which of those might be interfering with the
defrag, and what can I do about it?
Appreciate your indulgence.

Kiwi

On Sun, 19 Jun 2005 19:52:09 -0400, Rick T

Not by much; Scandisk is mechanically fairly gentle, steppingthe heads
along one click at a time, unlike the old shake-n-bake tests like
Checkit that deliberately set out to provoke harmonic distortion via
butterfly and random-seek tests.

Because sick sectors provoke retries, reading all sectors is apt to
provoke holding the heads over sick areas of disk, which might be bad
if you combine surface ripple and polluted air space with possible
head and further surface damage.

If you think the HD is sick, then I do agree with you; pull data off
first, before testing.  My own approach is to do that if I have reason
to suspect a sick HD, else I'll do the surface scan and watch the
first bit for latency.  If I see latency, old "B"ad blocks or get
explicit errors, I'll abort the test immediately and pull data off
first, and only then repeat the test.

The way Scandisk works, that's implicit.  It won't start the surface
scan until it passes through the logic testing phase, and it won't
pass through the logic phase unless it's allowed to fix almost
everything.  If you decline to fix something, it aborts - with one
bizzarre exception; it lets you continue checking with unfixed
mismatched FAT (!!!).

The logic behind this seems to be orientated towards fixing, rather
than checking only.  Logically, you'd want to spare a physically ill
HD the exertions of checking the file system structure, so you'd want
to verify physical health first.  But if you intend to "fix" surface
errors, that involves writing new data clusters and chaining them into
place, and it's dangerous to do that if you haven't verified the file
system sanity yet - hence "check/fix logic, then check surface".

However, continuing checking and fixing when you *know* there's a
serious file system error present (mismatched FATs) makes absolutely
no sense at all.  Smells like bad RAM somewhere in the dev's frontals.

Long File Names were retro-fitted to the file system in 1995, with the
advent of the original Win95.  The original 8.3 names remain in place,
and MS-DOS or DOS mode see only these.  

The extra information holding the Long File Name is held in extra
directory entries that are designed to appear invalid and be ignored
by MS-DOS and DOS mode, by setting an illogical set of attribute bits
that say "this is a volume label" and something else that is
inappropriate for "real" volume labels, at the same time.

Normal file operations use "opt-in"logic, i.e. they use only what they
are looking for - so they ignore such entries and don't do anything to
affect them.  But file system management tools may look for such
anomalies to "fix" them (Scandisk) or shuffle the order of directory
entries (directory sorters, Defrag) in the interest of speed or
cosmetics.  If the position of LFN entries is altered, either with
respect to themselves (a Loooong File Name may require multiple
entries for the same name, and these have to be ordered correctly) or
to the 8.3 name they are associated with, they break.

Windows itself is dependent of LFNs such as "Program Files", "My
Documents", "Microsoft Office" etc. and if the LFNs are destroyed,
these revert to pure 8.3 names such as PROGRA~1, MYDOCU~1, MICROS~1
and so on.  References via the LFNs will no longer find them.

If you run a tool that is dangerous for LFNs from DOS mode, the system
will lock up to protect them unless you UNLOCK the volume first (and
Yes the "Are you sure/mad?" prompt).  There's no such protection in
MS-DOS (or raw DR-DOS, IBM PC-DOS etc.) so the damage will be done.

That's why I'm so shrill about NOT defragging a Win95+ file system
from DOS, outside of the GUI.  It's an uber-bad idea.

See http://cquirke.mvps.org/lfns.htm

If you're defragging a volume other than C:, which contains no LFNs of
consequence, then OK.  Personally, I'd not roll those dice - hours or
days of downtime while you fix up the mess will offset any time saved
by speeding up file access as a result of the defrag.

A VW beetle at 60kmh is faster than a Ferrari parked with flat tyres.

   Hmmm... what was the *other* idea?