galileo

Debug log forwarded by PM. Running XPP+SP3 fully updated+Threatfire+PrevxEdge (no other AV or AS) This particular defrag left only one block showing "0" files - other defrags have left more than one such block. galileo

Degraggler 1.08.132 - after completing a defrag the drive map still shows light blue shaded blocks that are indicated as containing "0" files...this was was said to be corrected with the release of this version...is this still an issue that is awaiting correction... ...? galileo

Keep in mind that defragging is much like solving a puzzle - in order to collect all fragments of a file and order them into one contiguous string there must be at least as much contiguous free space as what the defragmented file requires. So, many times you will have to spend as much time creating freespace as you do defragging. I have frequently run across the same issues as you have...when there are numerous large files. Mine tend to be with multiple hard disk (or partition) image files which are usually in the 2GB to 35GB (yes ...that is 35GB) sizes. I suggest the following method of attack (with Defraggler): 1 - Defrag the Freespace allowing fragmentation - this is to prepare the maximum amount of contiguous freespace as you can 2 - Analyze the drive and from the File list tab select the bulk of the small files (<100MB) and defrag those files 3 - Analyze again to see if you have used up the contiguous freespace - If "yes" then Defrag Freespace but, do not allow fragmentation 4 - Analyze again and from the File list tab, start selecting a few of the larger files and defrag them - don't select too many files at any one time 5 - Repeat steps 3 and 4 and gradually work through remaining files on the File list tab - selecting larger and larger files on each cycle This process proceeds in a stepwise fashion to not only defrag the files but to keep recreating as much contiguous free space as you can so that the larger files will have the room (i.e. freespace) to be "assembled" into contiguous files by Defraggler. Keep in mind that as you cycle through larger and larger files, you will reach a point where you will only want (or be able) to select and defragment one file per cycle...otherwise you will not have adequate contiguous freespace and will just be wasting time waiting for an unsuccessful defrag cycle to complete. Theoretically, the defragger itself should be performing something similar to this cycling...but...the algorithm that is coded into the defragger may not be quite sophisticated enough to deal with "really" large files. This is a time consuming process....but it does work...even on 35GB files! Good Luck...... gallileo

Thank you! Is there any chance that your Defraggler code can be modified to actually provide the abilty to defrag pagefiles that are not in-use...???...as in the dual-boot arrangement that I described above. galileo

@MrRon: Thanks....and while your at (chuckles)...take a look at the light blue blocks that are left on your drive map after a defrag is completed...if one re-analyzes and looks at those blocks you will see that Defraggler reports them as containing no file(s)....yet they are still identified on the drive map with the light blue coloring...it would be desirable to have them cleared of any color if they are in fact empty...Thanks again!!! @gunner: This issue here isn't an install issue nor a dependency issue - the partitions are autonomous as far as the active, or in fact each, OS is concerned. Rather it is a file and/or file status identification issue. Per published literature, the Windows XP APIs are not supposedly capable of defragging certain system files, the pagefile being one of those. This is a limitation attributable to the OS and to the "in-use" state of that file. However, a pagefile that is not in use (i.e. effectively offline) would satisfy the API requirements that are required for any files that the APIs can defragment. Most likely the issue here is that Defraggler "sees" the pagefile as simply another "file" since it is not in-use and is ignoring its system file status when performing a full disk (partition) defrag. But, when attempting a single file defrag, Defraggler is "seeing" and acknowledging the system file status (irrespective of it being offline or not in-use) and thus, refusing to defrag, or even touch, that particular file. The intriguing potential here is that since Defraggler uses the Windows APIs and not custom code for its defragging operations, a dual boot arrangement wherein a pagefile is effectively offline may present an opportunity for Defraggler to actually execute a defrag of that pagefile - including possibly relocating that file to an optimum part of the drive.... Conversely, the problem or annoyance here is that Defraggler is actually moving parts of the offline pagefile(s) and causing defragmentation of those files. Thus, either Defraggler needs the code (i.e. intelligence) to recognize offline pagefiles and defrag them as typical files, or it needs some added code to make sure that it always leaves pagefiles alone irrespective of online or offline status. My hope is that perhaps there is a loophole in the APIs that will permit Defraggler to do something that has heretofore not so much been impossible but, has rather has not been recognized as possible. And, in so doing, perhaps this can be extended to other system files that are in the same offline state. This would be wonderful from a system maintenance perspective.... On a note of personal preference, I really don't like using 3rd party boot manager tools...the potential for issues with the MBR/PBR records is simply too great. If one ever needs to utilize any recovery console tools (i.e. fixmbr, etc.) you can trash other OS and/or data partitions due to items having been written to the MBR that are not recognized by the standard OS tools....yes, such 3rd party tools "function", but.....you can place yourself in a real "house-of-cards" with them....my comments juuuuusssssst might have something to do with some past experience... Nonetheless, thanks for chiming in on the conversation !!! galileo

@Mr Ron: On dual boot multiple partition installations - i.e. where a dual boot environment consists of the OS (XP in this case) being installed on separate partitions ~ say C and D drives - when using Defraggler to defragment a drive (partition) containing an OS install that is not currently booted Defraggler WILL actually move the pagefile on that drive during the "Defrag" (whole drive) operation. The result frequently is that the pagefile will end up in multiple fragments due to Defraggler apparently attempting to defragment it. Strangely, this is true even if the pagefile was already contiguous. This is a nasty issue in that contiguous pagefiles are being "fragmented" by Defraggler - when Defraggler runs a whole drive defragmentation against an offline OS drive. This behavior obviously does not occur when running against the online OS drive and pagefile. However, if one then attempts to explicitly defrag the offline pagefile by selecting it using the "File list" tab, Defraggler will, presumably by design or via the API limitations, refuse to defrag it - even though it just did attempt to do so under the "Defrag" (whole drive) option. I understand that the Windows APIs are being used by Defraggler and that the APIs do not support pagefile defragmentation...or are not supposed to support such defragmentation. However, keep in mind that Defraggler's behavior is occuring on the "offline" OS partition and thus, an offline pagefile. This behavior is in apparent contradiction to all information regarding the inherent ability of the OS APIs (Windows XP) to defragment a pagefile...at least an online pagefile... "If" the APIs are in fact supporting the defragmentation (i.e. file movement) of an "offline" pagefile, as evidenced by Defraggler's behavior in this dual boot environment, is it then possible to correct/modify the Defraggler code to "correctly" handle offline pagefiles when booted into an alternate OS partition...? Or, conversely, can this "fragmenting" behavior be prevented...? Sorry for the long winded treatise...but, this behavior was quite surprising...and both annoying in that contiguous pagefiles are being fragmented and intriguing in that Defraggler may well be able to handle pagefile...and perhaps MFT defragging if one is booted into an alternate OS partition and running Defraggler against the offline OS partition. This is strategy does leave the other OS partition in an "offline" state....FWIW. I have verified this behavior of Defraggler in multiple instances...it does in fact actually happen...you will need to create a dual boot system in order to investigate this. galileo

@MrRon: The issue here appears to be the same as discussed in the topic: "Defraggler confused over compressed file sizes". In my cases, the compressed drive uses Windows' native drive/file compression - not a third party compression tool. galileo

3rd confirmation....Defraggler exhibits this behavior on large capacity drives with numerous large hard drive image files - say half a dozen ~ 5GB to 40GB files. The larger the file size the worse DF functions. Not only is the success of a defrag an issue, the length of time to complete a defrag is also an issue in that DF continues to try to move files around to solve (i.e. complete) the defrag "puzzle". The defrag cycle time can become rather longer that using Windows defrag - which actually seems to do a better job with the large files than DF....assuming there is enough free space for it to function. BTW: This large file issue also seems to manifest itself on uncompressed drives as well. Even when there is more than adequate space for a complete defrag (say 70% free space), one stills ends up with fragmented files. Generally, a large file (say ~ 30GB) will frequently end up with 2 to 4 fragments after DF completes. As the file sizes grow larger, DF seems to be exhibiting both a less reliable (i.e. less successful) behavior and a notably slower behavior versus Windows defrag - or versus e.g. Diskeeper. This behavior does not seem to occur where the file sizes are generally below 1GB. galileo

Yes, there can be issues (yep, I have read prior postings on this topic... ) with removing KB's from the $hf_mig$ folder - but only in particular circumstances. It is my understanding that those issues are related to file versioning versus file dating. Wherein, MS issues an update or other software containing a file whose date may be newer than the file currently installed but, whose version identifier is older. In those instances the newer "version" is utilized by installing it from the $hf_mig$ folder. This condition is actually related to trapping update errors within MS's own updates or other software installations. It is worth taking a look at the MS literature on this subject... In the case of an SP, all of the files will be comprehensively replaced by the most up to date files irrespective of dating and versioning. Thus, retaining files from old KB's which have been "replaced" or, in fact, superceded by the SP is unnecessary. Additionally, and again my understanding, once an SP is installed, the registry links to the old KB's are in fact deleted (take a look at the HKLM\Software\Microsoft\Updates\Windows XP keys)...thus, there is in fact no way for the old KB's to be accessed in any case (it is odd that the superceded KB's are not deleted along with the links). Regardless, retaining old KB's which have been superceded by an "official" SP is even worse than redundant in that they are not only unnecessary but, would potentially conflict with other files installed from the SP. Hence, a cleanup utility which coordinated removal of KB's superceded by an SP would not only be harmless but, would be beneficial. One way to illustrate the harmless aspect is to perform a clean XP-SP3 install using a fully integrated source...say, MS's own XP-SP3. This will result in no $hf_mig$ folder being created at all. Compare this with any upgraded installation - prior to performing an SP installation there will be an $hf_mig$ folder with the old KB's from prior updates. After performing an SP installation, the old KB's will remain. However, as evidenced by the clean XP-SP3 installation, those which the SP updated are obviously unnecessary....otherwise the clean XP-SP3 install would be defective since it would be missing the old KB's... You are correct in that a careless removal of "all" the old KB's may create downstream issues. However, a removal that is coordinated with a given SP level would not. And, this is where an enormous amount of old "crap" can be "cleaned".... .... Early versions of CCleaner did "whack" the $hf_mig$ folder's contents and did result is downstream update issues...I remember those. However, "whack" is the operative action that took place then. A more careful and "surgical" deletion of superceded KB's would not re-create those problems.

Let's see if we can resurrect this item. For those users who have been methodically updating ever since they got their machines (i.e. those who have not re-installed), their $hf_mig$ folder is typically "huge". I am managing an environment in which many of the machines have 500MB to 1GB sizes for that folder. For a post-SP3 situation, in which an SP3 uninstall is no longer deemed relevant, there is no need to retain either the SP3 uninstall folder or the old KB's that have been superceded by SP3. From a cleanup perspective, it would be very desirable to remove both the SP uninstall and the KB's. The logic noted in the post above makes sense in that the removal option would only be relative to the SP level that the OS is at. Thus, separate removal options for SP2 and SP3 - assuming earlier SP's are somewhat rarer and more minimal in update KB's. This would represent a large untapped cleanup option for CCleaner to address.....

Simple command file (2 lines): c:\progra~1\defraggler\df.exe x: shutdown -s -f ...there ya go...put it in the task scheduler if desired or execute manually from a desktop link

@ MrRon & MrG When using "Defrag" or "Defrag Freespace" the result upon completion will frequently leave isolated or stranded used blocks on the drivemap and thus, I am assuming, on the actual drive. The "freespace" is not truly being defragged or "compacted". These stranded blocks are an issue as other files are saved to the drive and - much more importantly - as dynamic pagefile and/or MFT spaces grow these are by necessity fragmented around these stranded blocks. Can this issue be addressed so that freespace is in fact defragged - or alternatively "compacted"...?

@Defraggler Team: Can you shed any light on what is happening with development since the RC2 release Its been a little longer than your usual cycle since the last update.... Thanks! galileo

@MrG RC2 "feels" better (subjectively speaking). The added buttons on the File List tab are a notable improvement - now its clear what one is doing with respect to files. I like the Defrag Folder and Defrag File options. From a performance perspective, I would really like to see options for moving all folders to the front of the drive (ala JKDefrag et al) and for respecting "layout.ini".... The opening screen "Defrag" button still leaves one wondering in what context the "Defrag" would be conducted. Perhaps adding additional button text such as - "Defrag Drive" or "Defrag Partition" (or "Defrag X:" i.e. the currently selected partition) - would help define in what context one is about to conduct a defrag (similar to your "Defrag Checked" button text). In fact it would be convenient to have buttons for both....(?) The overall interface still seems a jusssst a bit too busy (not to be critical....just a sense or an initial impression when opening the program). My "sense" is that the menu bar, drive list, drive map, drive tab, file tab, and buttons "seem" to (almost) create a bit of visual confusion...but, then again, I am not exactly sure what I would change either...and I've even suggested some additional items... (at self) It might be quite "spiffy" to replace both the drive Properties and drive map with a circular drive map ala UltimateDefrag (~say placed in your "Properties" box???).....that would give one a real feel for where files are being placed on the drive platter. In fact, if the partition structure on the drive platter was highlighted that would be an even better representation than anybody (?) else offers to date. And, THANKS, for removing the "Are you sure" dialogs.... galileo

@MrG The more I use RC1 the more I am convinced that something is not right: Scenario #1: select a drive and click Analyze; then View Files; select all the files for defrag; return to the Drive tab; click Defrag....what is being defragged - only the selected files or the entire drive? The defrag seems to run noticeably longer than the previous version for just the selected files. After completing the defrag; Analyze again (no fragmented file are found); click Defrag anyway - a defrag begins....what is being defragged since there were no fragmented files nor was the "Defrag Drive" menu item selected.....??? The feedback should have been "No files to Defrag".... Scenario #2: select a drive; click Analyze; View Files and select...say about 5 small files; return to the Drive tab and click Defrag.....what is being analyzed....it seems like WAY more than the files that were selected. The defrag operation appears to proceed as though either all of the files were selected or as though the entire drive is being defragged; After completing the defrag, Analyze again (no files found), click Defrag anyway....the defrag process begins again... The feedback again should have been "No files to Defrag" Scenario #3: select drive; Analyze; DO NOT select ANY files; click Defrag....a defrag begins....the feedback should have been (you guessed it) "No files to Defrag".....something is broken. Scenario #4: select drive; DO NOT Analyze; click Defrag....a defrag begins....seem like a "No files to Defrag" or better yet, "No Analyze has been conducted" message should have shown up.....something feels broken. Something appears and feels broken between this build and the previous build(s). The interface has become more cumbersome to use and the previously elegant and quick file defragging process seems lost and "feedback" to the user "feels" disconnected. Most importantly, the quick defragging of selected files seems replaced by a rather lengthy defrag of considerably more than just the selected files. Please do not construe the comments negatively, rather, I love Defraggler and am offering constructive testing feedback. I am curious though, it also seems odd that you would make such a notable interface change as you moved from "beta" to "RC"...I would have thought that the progression to "RC" would in itself be a statement that the interface and features were frozen and that debugging the correct functionality had entered its final step.... Unfortunately, it feels that quite a bit has been destabilized (regression for sure) in this build.... galileo