Jump to content

Defraggler: Willy2's bug reports


Recommended Posts

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.

Screenshot_25.png

Defraggler1.png

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

  • 1 month later...

- 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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

- 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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

  • 3 weeks later...

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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

- 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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

  • 1 month later...

- 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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

  • 3 weeks later...

- 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 ?

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

- 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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

- 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.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

  • 2 weeks later...

- 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),

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.