Defraggler: Willy2's bug reports

[Willy2]

I noticed that the developers of Defraggler (DF) are planning a new version of the program. Well, then they only have to read this thread to see all the things that can be improved/fixed. And as they can see, I have come across A LOT OF things that can be fixed and improved.

Some of the bugs in this thread are clear and obvious bugs that need to be fixed and can be (easily (??)) fixed. But other bugs don't show a reliable pattern of when and where these bugs are occurring. In those cases I think this "irregular" behaviour can be fixed by, what I would call, "better protecting the internal DF variables" and/or improving the memorymanagement.

If I was asked to give a list of the fixes/improvements that have for me the highest priority then it would look like this:

1) Fix the multiple issues/bugs in the "Move files to end of drive" options which prevents the program from properly moving the all right files. See the 2 red arrows in the 1st picture.
2) Improve the "move to the end of drive" subroutines. In the 2nd picture I have an example. Here DF moved a number of files (blue boxes + red arrows) to the end of the drive. But after moving the files there are still (large) gaps (black line & black arrow).
3) Improve the "display blocks" routines. When I click on every empty box between 2 groups of blue boxes (above the black line) then DF reported that there were still some 4 or 5 files in that gap (above black line) but not all these files showed up in the file map between the files.
4) (Sharply) Reduce the time the program needs to stop. The user can decide to interrupt the program when the program is performing some operation (e.g. moving files to the end of a drive). But then it can take a LONG LONG time (up to 5 (10 ??) minutes !!) before the DF program code has really finished "stopping". The sign that DF is still (very) "busy" doing something mysterious, is the (very) high CPU as shown in Task Manager. And when I am really fed up, I simply use Task Manager to abort the DF process.

[Willy2]

- Have run Defraggler to move a bunch of files towards the end of the C: drive. I was astonished to see that, after having finished the job, the program kept running with a very high CPU for about 50 (!!!!) minutes. I know that it can take DF a considerable amount of time to "wind down" but ~ 50 minutes is ridiculous, outrageous.

[Willy2]

- I want to post a follow up on my post dated November 21, 2020.

- It seems - I repeat - SEEMS (!!!) that when the user sorts the search results on "Fragments" that then the program code acts as if the user want to sort the search results on "Last Modified". In this regard "Fragments" doesn't sort on "fragments" at all !!!

- The program code could contain a "Sort on fragments" sub-routine but then it seems this "sort on fragments" program code isn't used at all.

- The good folks at CCleaner should examine the "Sort on Fragments" program code in detail to see what's REALLY going on when the user want to sort the search result on "fragments". I can't make head or tails of it. But it simply doesn't work.

[Willy2]

Another follow up for the post of november 21, 2020:

Now I have a better description of when the "Sort Fragments" bug shows up.

- After the "Search" feature has produced a list with files that match a certain pattern, the user is able to sort the list on 6 criteria / benchmarks (Filename, fragments, size, type, last modified OR Path). The user can choose to sort the information multiple times on different benchmarks / criteria and as many times as the user wants to. Up to this point the sorting program code ALWAYS seem (!!!) to work.

- But the "Sort Fragments" bug shows up as soon as the user has defragmented a number of files or has reduced the fragmentation of a number of files. Let's assume that out of a list of say 40 files the user has defragmented say 4 files or has reduced the fragmentation of 4 files. Then when the user wants to sort the list on "Fragments" these 4 files remain "stuck" in their place in the "Fragments" list when the user sorts the list on "Fragments".

- The solution for this bug is/could be actually surprisingly simple. Because the "Sort Fragments" subroutine(s) in the "File list" tab simply ALWAYS work(s). Just do a simple "Copy & Paste" of the program code. Or perhaps the program uses the same "Sort Fragments" subroutine(s) but with some (slightly) different entry parameters ? Perhaps then a (small ??) change of the entry parameters could do the trick to fix this bug.

[Willy2]

- Another thing that can be improved in DF is the detection of the $MFT. Sometimes the drive map / the program code is "confused" where the $MFT is located in the drive map.

[Willy2]

- There are users who have complained that for Defraggler (& Recuva & Speccy) there weren't any new updates issued for a while. I am also one of those users who would love to see a new version of Defraggler with all the bugs/"Weak spots" fixed.

- I understand that some programs of CCleaner have (top) priority when it comes to issueing new (updated) versions. Like CCleaner. And that's quite understandable because programs like MS Edge, Google Chrome, Firefox and MS Onedrive are updated on a regular basis (say every 3 or 4 weeks). And that could mean that the program code of CCleaner also needs to be updated with top priority.

- But then programs like Speccy, Recuva & Defraggler don't receive too much attention when it comes to updating the programs. (Yes, I know that right now the developers of CCleaner are planning for new updates for 2 of these programs) That's why I would suggest / propose the following update policy for these 3 programs:

1) Collect all the suggestions & bug reports for these 3 programs.

2) If there is a need to issue an "Emergency update" then do so. E.g. when Microsoft issues a version of its "NET Framework" then SPECCY should be updated ASAP.

3) Dedicate one week each year to Defraggler, Speccy & Recuva. E.g a week per year for each program. Take all the reported bugs & suggestions and fix those bugs/implement the code changes for those 3 programs in those "dedicated weeks". If there are no bugs to be fixed in one program then that week can be used for something else.

[Willy2]

- I must add something to 3) in my previous reply.

#3 would only apply to bugs that are fairly simple to fix and don't take that much time to fix. And there are certainly still A LOT of those "small bugs" to be fixed.

[Willy2]

- Another problem with Defraggler: Lately another problem in DF has reared its ugly head. Sometimes simply selecting + highlighting a few files from the list in the "Search" tab pushes CPU to (very) high levels for several minutes. This would suggest that the combination of 1 or more programs running at the same time causes the CPU of DF to go "through the roof". But then the question becomes: what programs ?

[Willy2]

- Another problem has surfaced again. DF fails to detect / find the file "pagefile.sys" on my Windows 7 system. I tried to find "pagefile.sys" with the "Search" feature (in DF) but to no avail. DF finds A LOT OF other *.sys files but "pagefil.sys" is not found by DF.

- DF tries to defragment "pagefile.sys" upon system start up. The behaviour seems to suggest that DF finds the pagefile but isn't capable of doing anything with the file, in spite of having several large open spots on my HD.

- Yet, when I use 4 other programs (Everything, WizTree, WizFile & XYplorer) all 4 are able to find "Pagefile.sys". Odd, very odd. 

- When I start "clicking around" on the filemap (in DF) then a odd thing shows up. The drivemap shows blocks (scattered around the drive map) that are occupied but  when I click on those blocks the program responds with "No files in this block". It seems the program is a "bit too critical" when it comes too detecting the pagefile. Don't know what to make of it.

- Already tried if disabling and re-enabling the pagefile would make a difference. But again, to no avail.

=============================================

In addition to my previous post: this behaviour could be result of the program code "winding down" (/ trying to "wind down") colliding with some other piece of software. Or perhaps there was an "internal conflict" in the program code of DF itself. That's why - in my opinion - making sure that the amount of CPU - used by the program - is being reduced as fast as possible (after performing a task in DF) could / will have a very positive impact on the performance of the program and should have top priority.

[Willy2]

- Odd very odd. After turning the swapfile off and then back on again 2 times solved the "Pagefile.sys" problem. The pagefile now shows up in DF again. Again odd, very odd. But it seems that this problem has disappeared.

[Willy2]

- And another known bug in the program has resurfaced again. Defraggler sometimes moves files I didn't select. I assume that this is due to the fact that perhaps Df doesn't "protect its internal variables good enough".

Let's assume that I have moved files A, B, C, D, E & F towards the end of a drive (as best as possible) with DF. But I discovered that after say 2 or 3 months e.g. file C & D have been moved back towards the beginning of the drive again. I suspect that when I defragment say 10 or 100 other files DF also mistakenly moves that one file (C and/or D) towards the beginning of the drive again.

(No, I didn't use the build-in Window defragmentation program in the meantime (I disabled that program) or any other defragmentation program).

- It's quite possible that there is a link with the CPU remaining (very) high for MINUTES after DF has finished a task. In that regard I think fixing that "high CPU problem" will be VERY benficial for the overall perfomance of the program, will help to stabilize the overall execution of the program.

- I am aware that the high CPU is due to the fact that DF must do A LOT OF calculations in order to find a new empty spot on a drive where a file can be placed. Perhaps slowing down the execution of the program will help to reduce CPU and make the perfomance more stable. (just my 2 cents),

[Willy2]

- In the past I reported more than once about (very) high CPU usage when DF is "Winding Down" after the user has stopped one or more operations in DF. Last week I came across another example how this High CPU has a detrimental / negative impact on the program's performance. I wanted to change the size of the drive map. But the program code was still too busy "Winding down" (with high CPU) that DF didn't redraw (/ recalculate ) the drive map until that "Winding Down" was finished. The amount of time it took the program to "Wind Down" was simply too long and I decided to close the program and re-start it.

- I think that the focus of the developers of DF should be on (sharply) reducing the time this particularly annoying "Winding Down" takes. I think solving this problem should have "top priority", should be placed on top of the list with priorities for the DF program. This "Winding Down" problem - IMO - even warrants a separate update on its own.

- In the past I also wrote computer programs. Back then I learned that there were very specific guidelines on how to terminate a program that could be running for a long time. That one program had to regularly check the state of one variable. And when that variable was in one particular state (e.g. the user had pressed one particular key) then a program should the change the conditions in a programming loop in such a way that the program would abandon a program loop ASAP.

[Willy2]

- Another thing that nags me regarding this "high CPU usage" is the following:

I can decide to click on "Stop" button in DF when the program is busy moving files//looking for a free spot to place a defragmented file/ ........... Then DF supposedly stops executing the program. Then I can decide to close the program using the "X" in top right hand side of GUI of DF. Here I then come across the thing that's nagging me. Then a window shows up with the message (something along the lines of) "DF is executing a task. Do you really want to stop the program?". That's odd, very odd because DF gave me the impression that - although that CPU was still very high - DF had stopped all its "operations". In other words: This message "....... Do you really want to stop the program ?" shouldn't be displayed at all because supposedly the program had finished executing the program code.

[Willy2]

Yes, the program code of DF needs a very decent overhaul of the program code. I noticed that DF still moves files (in my case *.mp4 files ) towards the beginning of the drive without my consent. (No, I turned off Windows Disk Defragmenting program). It seems that DF hasn't got "all its ducks in a row" and then moves the wrong files (towards the beginning of the drive).

There could be a relationship with the High CPU usage when the user stops the program. Or perhaps DF takes the file from the memory (e.g. the socalled "Stand By" memory) of one's computer and then gets "confused" which files should be moved towards the beginning of the drive.

Or perhaps interrupting DF messes up the info contained by DF in the memory.

Or DF takes information from the file called "layout.ini". When I go through the content of this file then it also lists *.mp4 files that I have viewed in the (recent) past.

There is more than one possibility why DF doesn't do a proper job .........................

[Willy2]

- Update for the post of june 18, 2020:

The weblinks provided in that post have been removed and moved to new locations:

RAMMAP: RAMMap - Sysinternals | Microsoft Learn

Video weblink: Defrag Tools: #6 - RAMMap | Microsoft Learn

 

- Still no updates for Defraggler available or any plans for an update ? I am one of those geeks who use the program EVERY (!!!!) day.

[Willy2]

- This is a follow up for the post from february 2022. Defraggler keeps "annoying" (to put it friendly) me.

- I think (!!!!) I found a pattern in the program why DF keeps moving files towards the beginning of a drive without my consent.

- Firstly, I have the default Window defragmentation utility turned off. Secondly, I moved all the *.mp4 files (even the "......... . mp4.lnk" files) to the end of the drive as much as possible.

- Then I added a few .mp4 files to the drive. REAL PLAYER allows me to download these *.mp4 files from e.g. YouTube. These *.mp4 files were stored in fragments scattered around the drive based on the whims of Windows. Then I ran Defraggler to defragment these newly added *.mp4 files by using the "Defragment files" option and NOT the "(Defragment &) move to end of the drive" option.

- Here is it where it was getting interesting. It seems DF took a number (10 ??? 20 ???, I can't remember) of defragmented *.mp4 files (only *.mp4 files ????) which were NOT (!!!) selected by me in DF and moved them to a spot on the drive as close as possible to the beginning of the drive (without my consent).

- The odd thing is that when I used the "(Defragment &) Move files to the end of drive" option then I was able to move A LOT OF / tonnes of files to the end of the drive without DF moving a SINGLE file towards the beginning of the drive (without my consent). In other words: this "un-approved" moving of files towards the beginning of the drive only seems to happen when the user uses the (simple) "Defragment files" option.

- Why did do / is doing DF this ? It looks like DF in this case (with the "defragment files" option) creates an "internal list" of files to be moved (& defragmented) and that DF somehow adds one or more files (only *.mp4 files in this case ???) to that list and treats those newly added defragmented files as though they were not defragmented at all. Perhaps when the user selects say 10 (e.g. *.mp4) files then DF add an 10 additional (e.g. *.mp4) to that "internal list" ? But it remains unclear WHY DF is doing this and what the logic is behind this "moving files wihtout my consent".

- Well, the developers of DF should start improving the program code of DF right away. But I fear that improving DF is NOT (very) high on the list with priorities of the developers of CCleaner's development team.

[Willy2]

- Yep, it happened again. I used the (simple) "Defrag files" option to defrag a number of *.mp4 files. And then DF moved a number of defragmented files to the beginning of the drive AS WELL. Then I had to MANUALLY move these files to the end of the drive again.

- An analysis of the files that were moved didn't provide a clue what the logic was behind this moving.

[Willy2]

- Does it matter that I have a program called CLEANMEM installed on my Windows system. It regularly reduces the amount of "in use" memory. That memory is then moved to the "Standby" part of memory. Would that interfere with DF ? Would that throw DF "into disarray" ? It shouldn't matter because then the memory management should take the information from the "Standby" part of the memory instead. I'll exclude DF from being cleaned by CLEANMEM and see what happens next. Fingers crossed.

[nukecad]

I would point out that it's very unlikely that any functional changes will be made to Defraggler in future.

We have actually been told that is now 'defacto sunset'.

You may have already noticed that Defraggler Pro has been removed from sale and no longer included in the 'CCleaner Pro or Premium bundles.

Defraggler no longer needs a licence key it is a Free application now with all the functionality of the Pro version.

[Willy2]

No, this news is new for me. It's a REAL REAL REAL pity.

[Willy2]

Perhaps the bugs, flaws and "weaknesses" in the program code are still too complicated to be solved in a reasonable time ?

[Willy2]

If CCleaner has decided to stop the development of Defraggler then they should make an announcement here on the forum and pin it.

[hazelnut]

The last admin post on the forum  I recall about it was this,

https://community.ccleaner.com/topic/63004-wrong-media-type/#comment-336834

 

[Willy2]

That post only says "under review". Or is this a different way of saying "no more new improved DF versions" ?