ectotropic

I think you have misunderstood what I was talking about - I should probably have made it clearer, sorry. I realise that the page file is in use while running windows and so can't be defragmented - the only reason I mentioned it was to explain why I was also using diskeeper (since it is one of the few apps available that can defragment the page file in Windows 7 x64). The bug is not related to the page file, but to other files not currently in use. How the bug occurred: Closed all open programs and stopped all services able to be stopped (via services.msc) Defragmented all drives with defraggler till it told me no files were fragmented (excluding non-defragmentable files; page file, $MFT, etc) Opened diskeeper and analysed all drives Noticed that diskeeper said several files were fragmented Defragmented all drives with diskeeper (which defragmented several files) Analysed all drives with both defraggler and diskeeper Both now say no fragmented files (again excluding non-defragmentable files; page file, $MFT, etc) Note that on some drives defraggler listed no fragmented files at all (including non-defragmentable files), yet diskeeper told me there was files that were fragmented on the drive (which is was able to defragment). The bug, then, is simply that diskeeper apparently found and was able to defragment file that defraggler did not. I hope that makes more sense!

A couple of ideas on data placement that might be useful: "Isolate" frequently used files Complete defrag (with specific file order) In more detail: 1. Example, you have a version control system on a disk, generally the files will change fairly infrequently (the same file is not likely to be changed multiple times in a row), however the database holding file information will change frequently. If using a standard defrag, or even a "most often used" type defrag, this DB is likely to be placed flush on the disk with other files, which means as soon as it grows it will fragment again. A better solution would be if the file was placed with some free space following it on the drive - if this was placed near the end of the drive then it should help avoid future fragmentation (since placed near the start of the drive would likely mean Windows would use the free space for some other file). Allowing the user to select such files (in a similar way to large files moved to end of the drive) would be all that would be needed. 2. Example, you have a data drive that only contains music files - in this case the normal access pattern will likely be to play an album at a time or similar. In this case the best performance will be achieved if the data files are sequentially ordered on disk in the same order they appear to user (at least at the file level - so all files in any folder are kept on disk together). Any data drive that contains files whose sizes are essentially fixed could benefit from this. Just some thoughts - feel free to ignore me! (Apologies if either of these have already been suggested!)

I have been using defraggler for a while now and have been pretty happy with it so far, but when my page file became fragmented I was forced to turn to Diskeeper (trial install) since it seems that it is about the only defragmenter able to fix that issue for Windows 7. Will I was playing around with it I happened to notice that on drives that defraggler said there were no fragmented files Diskeeper often listed one or more fragmented files (and not files that were locked or otherwise inaccessable), which it was then able to defragment. I realise that different software can have different criteria for certain things, but fragmentation would seem to be a fairly black and white issue (either a file is fragmented or it isn't). For the record I'm using Windows 7 x64 with multiple SATA drives (2 data drives, 3 drives in RAID 0 - split into 2 partitions). I can happily provide any more information needed!