No, not at all.

No although if using ScanDefrag allows you to defrag without problem and
Defrag does not then I would suggest you stick with ScanDefrag.  The tool
uses the same defrag engine, the difference being that ScanDefrag that
runs during bootup and therefore is less likely to be interrupted by other
processes accessing the hard drive being defragged.

On Tue, 29 May 2007 18:04:00 -0700, Ben B

Yes - or with the same tool, if different options are applied.

However...

..are likely to work the same way, because (as I understand it)
ScanDefrag is just a wrapper for the same MS defrag.

Up until Win98, the defrag logic was pretty simple:
 - files split into multiple scattered pieces are Bad
 - all files should be close to the start of the volume

With Win98, a new logic (credited to Intel) was added:
 - commonly-used code should come first
 - if that breaks up large files with only parts commonly used, OK

A tool that applies the first logic, will consider a volume
"defragged" using the second logic to be badly fragmented.  This issue
caused a lot of "defrag wars", i.e. very slow and protracted
defragging sessions, when uses would alternate between logics, e.g.
use a pre-98-logic version of Norton Speed Disk one day, and Win98's
native defragger the next.  In addition, you could disable Win98's new
defrag logic and have it operate like the old days.

That issue is most likely to cause significant differences, but
there's more "detail" too.  In the DOS era, some tools let you select
and order "favorite" directories to be moved to the front of the
volume, while other options were to place all dirs before files, order
directory entries in different ways, only strive to defrag free space.
etc.  There's a school of thought that leaving some "loose" space for
temp work is a good idea, else you force heads to travcel from FAT and
first-installed OS code to the other end of the file mass to create
temp files or grow swap space and registry hives.

The other issue that is particular to the new logic, is on what basis
files (or parts thereof) will be considered to be "commonly used".
This is normally derived from usage information that is gathered by an
underfootware process (i.e. is active all the time, not just when
defragging).  Win98's defragger stores this in AppLog; other
defraggers may use this or run their own usage tracking service.

It may not matter much - if anything, ScanDefrag would prolly be the
one to "believe".  Differences may also arise with the same tool, as
the AppLog data changes with time.

For example, you defrag, install MS Office, and defrag again.  At this
point. none of the MS Office code has been run, so it's not in the
AppLog, and doesn't get special treatment; most likely it will be
"optimized" as non-fragmented files on the far side of the file mass,
just before an (ideally?) unbroken strech of free space.

Then you defrag again, a day after heavy use of MS Office.  If some
parts of some files have been tracked as often used, then these
fragments will be located nearer the front of the volume for speed.

What ScanDefrag does, is ensure there's as few files locked by being
"in use" as possible, so that they can be moved by defrag, and so that
writes to the file system do not restart either Scandisk or Defrag
from the beginning again (the main problem it was designed to fix).

The problem arises because (quite properly) neither Scandisk nor
Defrag will continue if the file system contents have been changed,
for fear of corrupting data.  I know that XP doesn't seem to have this
problem, presumably because it uses a finer-grained way to tell
whether a file system write will invalidate the programs' assumptions.

  I'm on a ten-year lunch break