Unclickable files, unmovable files, prematurely stopping defragging

[mvkkIGXk]

System info:

Windows XP x64 with newest SP and all updates and correct drivers.

Defraggler version: v2.13.670 (64-bit) (with the /debug3 switch)

Drive: 2 TB with TrueCrypt 7.1a encryption, approximately 40 % free space

CHKDSK with /V switch report no problems.

Drive contains no volume mount points or junction points, but does have some hardlinks.

 

I've encountered 4 problems:

1. Many "small" (up to a couple of 100 MBytes) files refuse the "Move highlighted to End of Drive" command on the right click menu. It looks like Defraggler does try to move them, they just don't move. Files larger than 250 MB seem to move OK.

 

2. When defragmenting the disk with "Move large files to end of drive during whole drive defrag" checked, the minimum file size set to 1 MB and "Move only selected file types" unchecked the defragmentation stops after moving just a few % to the end of drive without any kind of error message, it looks like Defraggler thinks it finished the job even though it didn't.

 

3. The graphical drive map gets completely disrupted while a move to end is in progress.

 

4. Some large files show up on the graphical drive map, but when holding the mouse pointer over it the message is "No files in block", and when clicking on it the "Highlighted" tab doesn't show. Also after using another program to determine the name of the file i can see that the file can't be found by the search tab.

 

I'm fairly certain my system is stable and the disk and filesystem are both error free. It seems to me that the first 3 problems are likely to be related.

 

Hope this helps find the bugs.

 

Any more information required?

[uds0]

The only way I was able to eliminate the 20 Meg contiguous purble block which shows no files or $bad clus: on 2 of 4 XPs I reloaded (which had error free scanned harddisks) was to use a little partition shuffle trick using excellent (both) free (to EVERYONE!) MiniTools Partition Manager and Backupper backup/restore (who also has very nice free for all Partition Manager). Both produce bootable cds so no need to install on hd, although WinPE version of Backupper only worked on 3 of 4 XPs and the Linux version is missing the backup feature (restore only) and is pretty basic (no partiton labels shown, etc):

 

1. Make an Image backup (for safety).

 

2. Resize partition to minimum + 300Meg AND move it up from the original start at least 300Meg. This crams ALL data on the partition into the front of it, including otherwise non-moveable files (can be MUCH faster than defragging free space (and actually works on all files))! Note that you can only restore to same or larger partition. WARNING: do NOT "align" partition (to 1 Meg partition start) if prior to Vista (XP). If you do, then all of the XP tools, including Partition Magic 8, will stop working! PM8 issues error #105 or #106 (partition doesn't start on even Cylinder, Head, Sector (xxxxxx,0,1) and end on (yyyyyy,254,63).

 

3. Make another image backup of squeezed partition.

 

4. Resize partition back to original size and position at start. Same WARNING as above.

 

5. Restore from squeezed backup image (tip: use advanced restore feature of resizing back to original size to avoid having to resize after restore via Partition Manager).

 

Tada! The "no file"/bad cluster file magically disappears!

 

Tip: User Journal files do not get defragmentter or moved, but you can use "fsutil usn deletejournal /n c:" to remove those pesky files. Please review the caution information about doing this (google fsutil). I haven't noticed any downside yet to deleting them.

 

Tip: use CCleaner set to remove win patch uninstalls (if you feel safe about doing that), clear software distributions\download folder, remove Service Pack 2 and 3 uninstalls (100s of megs) if not needed, and turn off all system restore monitoring (caution: will wipe out all restore points, but can free up many gigabytes, Turn back on when done). Note that CCleaner does not remove the patch uninstall entries in the registry unless you also run the CCleaner registry scan. Then use LargeFiles free utility to quickly display 100 largest files on the selected drive to see what else might be able to be trimmed BEFORE backing up.

 

6. Turn off Hybernation file (via Power settings) and Page file (remember to click set and apply on advanced performance setting on my computer properties) then reboot, then defrag. Doing this eliminates these 2 huge files so that defraging is done without them. Leave hibernation off or at least only enable if you actually use it (say, on a portable?) and set Page file (remember to press set button) to fixed 1.5 x RAM size (min and max) to avoid future fragmentation. Reboot required then.

 

Again, squeezing the partition down quickly consolidates free space and assures ALL files in free space are truely consolidated out of free space.

 

Hope this saves others the time I spent messing with it.

[Augeas]

Uds0, I've removed your almost identical, if smaller, post in another thread. Apart from double posting, people don't usually wait four years for a response to their queries.

 

Secondly, this post (to a mere six-months old thread) doesn't seem to me to be particularly relevant.

 

And finally I would advise anyone reading your post to be very careful about undertaking such changes, and to be fully aware of the possible consequences.

 

Please exercise a little caution and reasonableness when posting again. Thanks.

[uds0]

Thanks Moderator for clarifying your policy.

 

First of all, I want to express my extreme appreciation for such a powerful and easy to use app provided in the spirit of giving freely. Hopefully this discussion might help add a bit of value to that tool by focusing on an area that has potential improvement.

 

Since the solution I posted directly solves the inability of DF to move unmovable files (even after reboot defrag) from the free space, I respectfully submit that my solution is very relevent to this thread.

 

I fully support minimizing double posting. The other posting content addressed a significantly different issue: invalid bad clusters not being dealt with, which the same partition squeeze seems to solve. I agree that everyone should ALWAYS do image backups when they take extreme measures to more fully deal with all the potential garbage windows keeps, which is why it is the 1st step in my process enumerated in my prior posting.

 

I hope that everyone understands that anything, includingh clearing the free space with DF, that fills up the partition (squeezing it to minimum has a similar effect) can cause the loss of many if not all system restore points. I love the DF tools feature to easily see restore points and remove all but the most current - much more convenient and quicker than the way windows buries it in a subtle submenu, and again, potentially very hard on a casual user.

 

BTW, answering an old thread much later does at least provide a potential answer that is still very relevent even now to an old issue that was never solved. Just because I didn't spot that thread until now doesn't mean the issue doesn't deserve a useful response.

 

More observations on the current topic - back to basics ...

 

Alot of folks have expressed a lot of frustration with not being able to defrag free space completely, especially when they wanted to reset the pagefile and hybernation files to be contiguous directly after all files on a totally defragmented drive.

 

Again, simply resizing the partition to minimum size (and "applying") and then resizing back to original size eliminates ALL of the free space fragmentation.

It is a partition operation that warrants caution, and it appears to be benign in my experience. Since this simple process handles unmoveable files, it is much more effective that the free space defrag (and potentially a lot quicker). I have never had a problem doing this. Note that a freshly formatted XP partition puts the system files somewhat down the free space and those files and structures are moved to the beginning of the drive by the minimum size resize process. I understand that this is the fastest part of the drive, so this may be another possible benefit?

 

Restoring an image of an o/s partition to a different sized partition some times causes a sytem to stop booting, and every time it has been fixed by setting the o/s partition Active (somehow reset by restore).

 

I used the XP SP3 Disk Management tool to reformat a 20 Gig non-o/s data partition. Running Defraggler Analysis now displays 3 full rows (out of 23) of purple (MFT per color legend), or 13% (2.61 Gig!) of the drive space. The first purple block shows the $MFT at 52k, $MFTMirr at 4k, the $Logfile at 65.5k, plus $UpCase, $Bitmap, $Secure:$SDH. The XP Disk Defragmenter reports 66MB used of 20.15 GB and confirms $MFT size at 52k (51% in use) in 2 fragments. Chkdsk also reports the $Logfile as 65.6k.

 

An image backup/restore (without resizing) using Backupper did not eliminate the purple blocks (but did move them down a bit so that substantial free space now appears above them. Reformatting or Deleting and recreating the partition using MiniTools Partition Wizard also didn't seem to affect them (space above still there too). Reformatting using Format d: also had little effect (placed 3 rows of purple about 1/4 down from start of partition, about the same place). Finally, minimizing the partition size and moving it up a gig, doing an image backup using Backupper, resizing back to full size and starting at original position, then restoring squeezed backup (using the advanced restore feature to reset the minimal backup partition size to the original full partition size during the restore process) produced about the same size contiguous purple area but moved it much closer to the start (starting about where the squeezed partition start was moved to?).

 

All of this leads me to conclude that the large purple area is, in the end, expected windows behavior, although, for some odd reason, a few of the partitions do not have nearly as large of area even though they are the same partition size on freshly partitoned drives. Wierd!

 

Perhaps the 2.6 GB is reserved for the $MFT plus other NTFS system files? This seems way overboard to me, but I cannot tell since ALL other purple blocks (after the 1st) are reported by DF as "no files are in block"?

 

As others have commented, alot of confusion, concern, speculation, and much effort messing with this trying to minimize or at least consolidate this large area could be avoided by reporting the actual system files (or at least generic "system files") rather than "no files".

 

Now if DF only used the windows start up order file contents to optimize windows start up file placements like several other defrag utilities do, I would be even more impressed! I'll post to feature request list if I don't find it so feel free to delete the previous sentence if I forget to minimize double posting.

 

Hope this helps!

[uds0]

A bit more testing ...

 

I loaded the free version of PerfectDisk to hopefully get more distinctions. It displays the 1st MFT block as yellow and the MFT expansion reserved area directly following it in olive green. Both areas combined match up with the single purple MFT area in DF. PD fortunately shows "MFT zone" (should be "reserved MFT zone"?) for the olive green blocks, whereas DF shows all blocks as purple MFT, "1 file(s) in the block" in 1st block, and "no files are in the block" for all others. Although this "no files" is technically correct, it begs the question: Then what is really there? In addition, PD placed the unmoveable system files in a contiguous area about mid partition. This may make performance sense because they are accessed alot and being mid partiton may provide the best average head travel access speed? DF does list the files in each block on both system and non-system files, whereas PD doesn't. This feature of DF is much more useful to me.

 

Now if DF would automatically analize all partitions on startup (as PD does) as an option, that would be nice! <g>

 

Another nice feature of PD is not requiring a reboot to run boot time defrag on partitions that are not being accessed (typically data partitions when all apps are closed). I know I'm musing (wandering), so bear with me ...

[DennisD]

Hi usd0.

 

This section of the forum is to simply report a bug in Defraggler.

 

Post #4 goes way beyond that, and as stated by my friend Augeas in post #3, what you are outlining isn't the sort of thing we would recommend any member on here to get into.

 

You are now, in post #5, getting into a comparison between Defraggler and Perfect Disk.

 

This isn't what the bug reporting section is about so I'll close this topic before it goes any further, and in future could you keep any bug reports brief and concise.

 

EDIT:

 

@ the original poster mvkklGXk. If you would like the topic reopened to add to your comment, please pm me.