Most of the information given above, while somewhat helpful, is simply not applicable to the problem at hand.

While there are certain programs that can write to the drive and "change the contents," and these programs should be turned off to do a defrag, Safe Mode is not particularly helpful, and Systray does NOT normally interfere with defrag.

In the olden days when everyone used the simple FAT disk (FAT16), the "root sector" was a fixed length - regardless of how much information was on the disk. ONLY the 8+3 DOS filename, a few (4+) attribute bits, the file length, and the cluster location of the first cluster in the file (or folder) was recorded there. Each cluster contained the location of the next one in the file or folder.

FAT (FAT16) structure cannot be used for large disks, since it doesn't have enough space to write more than "a few" file addresses. It also cannot efficiently "service" long file names, and since the "root sector" knows little about the overall structure of the disk, it can't do a very "efficent" defrag. Defrag with a FAT structure can take a very long time, simply because it can't do anything except move files one at a time, in the order encountered, to close up all the gaps. Since it must write a file that's to be moved somewhere "high" on the disk, then must verify the write, then must re-address the location of the "new" file, and then do the same thing again to move it back - if there is a one byte gap at the beginning of the disk, it may have to write every byte on the disk at least 4 (or 8 or 16) times. But it doesn't restart too often - it just takes a very long time to complete.

With FAT32, the "root folder" takes over the bookkeeping tasks, and it is permitted to be any length - and can change it's length when the information recorded there changes. If the first few clusters are "densely compacted" - i.e. defragged, a change in the length of the "root folder" means that adjacent clusters must be moved to make room - or to close any gap that appears. The vast majority of the "disk contents changed - restarting" messages during defrag of a FAT32 disk are the result of changes in the length of the "root folder" information - and ARE NOT CAUSED BY OTHER PROGRAMS.

Compared to a FAT root sector, the FAT32 "root folder" contains an immense amount of information, but some of the information is "optional" and may only be "filled in" during a defrag. Of course, when it finds a file or folder with additional information, adding that information to the root folder may change the length of the root folder - which means the file that supplied the information (and all other files preceding it on the drive) may have to move, so the information will be incorrect when defrag gets back to it - which means doing it all over again.

Usually, the second pass on one of these "rich data points" will resolve the information, so that after the third restart defrag will pass through this point - but: the next "rich data point" may change the root folder length - which makes the data for the first "rdp" wrong again, requiring 3 more restarts to fix it for each of the 3 restarts required to fix the second one. This behaviour is BUILT IN with FAT32 disk format under Win98. If you have "N" rich data points that will add information to the root folder during defrag, you COULD potentially get (3N)! restarts. (For N = 3, that's 362,880 restarts.)

The situation is less dismal than it might be simply because there's often quite a bit of slop left in the last cluster of each file, so that small changes in file size don't often affect where the next file starts.

With Win2000 and WinXP, defrag compacts files but doesn't typically attempt to compact all of the free space between them, leaving a little "headroom" so that restarts are much less frequent - although they still seem to occur. With NTFS disks under those two systems, they are not observable so far as I've been able to tell.

If you have a program that you know might write to the disk during a defrag, by all means turn it off; but cripling Windows by turning off things that don't affect the defrag operation will only assure that you'll never get a full and effective defrag, and the situation will never get better. Under Win98, with a FAT32 20GB drive, I've seen as much as 23 hours for a defrag, but subsequent degrags - once the disk has been "sorted out" seldom took more than about 3 hours. I'll note that the "record" 23 hour defrag in Windows came immediately after a SAFEMODE defrag that did a "dumb" job of it and scrambled the "efficient" file sort that Windows wanted.

John