Jump to content
Piriform Community Forums
Willy2

Defraggler: Willy2's bug reports

Recommended Posts

- Auslogic Defrag was able to pull up the location of the fragmented pagefile (See picture, in highlighted black) and told me that it had four fragments. But DF wasn't even able to detect that the pagefile was fragmented. Perhaps DF is too critical when it comes to the pagefile and then decides it isn't there ? "Rogue" registry setting ?

or is it that you have defraggler set to ignore pagefiles? Just checking, also try not to reference competition that's why I pm'd you

Share this post


Link to post
Share on other sites

- No, I didn't exclude anything. Can DF be set to ignore the pagefile ?

- BTW, I prefer DF over .............. because DF has more options to "move files around". (Although it still can be improved)

Share this post


Link to post
Share on other sites

- Used another program ( ....................... ) in an attempt to defrag the pagefile but it only increased the defragmentation (from 4 to 12 fragments). But surprisingly, after using that program, now DF recognizes the pagefile again and it was able to reduce fragmentation to (only) four fragments.

Share this post


Link to post
Share on other sites

- Here's another thing I don't like in DF. Regularly DF uses LARGE amount of CPU. Especially when it must move files towards the end of the drive.

- But what's REALLY "annoying" is what happens when I have moved A LOT OF files (for the time being I only have seen this when these files were moved towards the end of the drive) and close the program. Then it regularly happens that DF fails to close itself and keeps running for another say 60 to 90 seconds with very high CPU (Task Manager says it's at about 25%). I also can hear that because then the cooling fan is "working overtime".

Share this post


Link to post
Share on other sites

- More bad news for DF v2.21. My pagefile was in 3 fragments. DF recognized that the pagefile was fragmented. Because upon start up DF wanted to defrag the pagefile. But after say 10 to 15 seconds DF apparently decided it was unable to do so. DF moved on to defrag other system files. And that was in spite of having enough contiguous free disk space for a defragmented pagefile of 8 GB in size.

- I had to use a program called ............. to get that pagefile defragmented. It took ........................ several minutes to get the job done but after that the pagefile was defragmented.

Share this post


Link to post
Share on other sites

- When DF is using A LOT OF CPU then it's "unwilling" to close itself. Then one can click on the "X" in the top right hand of the DF GUI and then that GUI disappears. But Task Manager tells me that DF is still running with high CPU. I then usually manually close that process using that same Task Manager.

Share this post


Link to post
Share on other sites

- I told DF to not show the System Restore Points (SRPs). That works well for the "File List" tab but when I use the "Search" tab then these files showed up in the list. I searched the drive for files that contain "." and those SRPs showed up in the file list. And that's in spite of those files not having a "." in their name and no extension.

 

- At the same time: when I highlighted one of those fragmented SRPs (in the file list) DF highlighted that same SRP in a colour that suggested that this file/SRP was not defragmented.

Share this post


Link to post
Share on other sites

- DF's algorithms to move files towards the end of the drive have something in common. (or is there only one algorithm ??). These algorithms don't move all selected files. There's something that interferes with these/this algorithm(s). I could imagine that DF fails to "protect" the part of the memory where all the file info is stored.

Share this post


Link to post
Share on other sites

- One more bug: Some message boxes don't take into account that I have the Task Bar on the left hand side of my screen. Then the left part of those messages boxes are hidden under the Task Bar.

Share this post


Link to post
Share on other sites
- One more bug: Some message boxes don't take into account that I have the Task Bar on the left hand side of my screen. Then the left part of those messages boxes are hidden under the Task Bar.

Isn't that more of a windows problem, ive had that occur whenever my taskbar was in a different place or auto-hide

Share this post


Link to post
Share on other sites

- No, I know that it's a matter of determining where the left hand side of the screen is (including or excluding the Task Bar.).

- I also know that some programs (part of the Windows OS) also don't perform such a check. E.g. Open CMD.exe and start fiddling with the window.

- See the attached screenshot as well.

post-21462-0-31009800-1472753464_thumb.png

Share this post


Link to post
Share on other sites

- After "closing" DF the program can remain running (See Task Manager) with high CPU. I made 2 screenshots of what's going on. See attachments (I have a dutch version of Win 7).

post-21462-0-28732000-1473614345_thumb.png

post-21462-0-09138500-1473614383_thumb.png

Share this post


Link to post
Share on other sites

- There's still one thing nagging me in DF. When DF wants to move a bunch of files to(wards) the end of the drive then the program code doesn't check whether or not that move would place those files closer towards the begining of a drive. See the picture (weblink) for an example.

 

When I order DF to move a list of files then e.g. the file marked by the blue arrow can be moved to the spot marked by the red arrow. So far, so good.

 

But the same DF program code also can (& will) move the file marked by a black arrow to the spot marked by the red arrow and that's something I don't like. It also means that I can't use the automated move of files. Currently I must manually move files towards the end of the drive to get a better result.

 

- The picture also show something else that can be improved. The red arrow points to 2 grey blocks that are in the process of being written. But according to the user defined settings those 2 blocks should show up in the color black. In other words, DF doesn't highlight those blocks.

 

- DF can cause problems when the program is automated to be run upon start up. I have seen that - at least - 2 Vista users noticed that they weren't able to create Restore Points any more. Because in that circumstance DF seems to have "broken" the Volume Shadow Copy sub-system. Does anyone have any thoughts / experience(s) regarding this problem / complaint ?

 

(I know, the combination of DF and VSS is a cumbersome one)

 

https://1drv.ms/i/s!AluvxwylJSzyeLd4CgI3c-5RnHE

Share this post


Link to post
Share on other sites

- Another odd thing in DF.

 

Assuming that I have 2 fragmented files (File001 & File002). Let's assume that DF defragments File001 first and then File002. When DF is busy processing File002 then DF will report that it's still busy defragmenting File001. To be fixed in the next version !!!

 

(I DO hope there'll be a new version of DF issued in the (near ??) future. I have given enough reasons why a new version of DF is justified)

Share this post


Link to post
Share on other sites

Willy2 well done suggesting fixes.  I might ask why it is that if an the average 'Defrag' takes hours and the average system is set to Sleep in thirty minutes, the system doesn't /at least have a non-default option/ to disable sleep while it is active?  It is poor planning from the average novice's view.  Just my 2c, thanks.

Share this post


Link to post
Share on other sites

Found two language related (non fatal) issues/bugs in the last version of DF.

 

- Found a translation error: DF is able to search a drive only for filenames or parts of file names (incl. extensions). But the dutch translation states that DF also can search for (parts of) folder names.

 

- Another language related thing that can be improved in a future version.

 

When I want to select the folder "C:\Users" on my dutch Win 7 system (See my signature) then DF does always pull up and displays the right dutch name for that system folder ("Gebruikers").

 

But here's where DF gets "off the rails". To allow the user select one or more folders, the names of the folders needs to be sorted alphabetically. Then DF doesn't take into account that that folder is called "Gebruikers" on my dutch system. Then DF assumes that that folder is called "C:\Users" and not "c:\Gebruikers". And then the list with folder names is displayed accordingly.

 

As a result the folder "Gebruikers" ends up (in the sorted list) between "C:\Uitzoeken" and "C:\Videos".

 

See this screenshot:

https://1drv.ms/u/s!AluvxwylJSzygRXEXtjWw0XlNuxf

 

I assume that this sorting problem is not limited to dutch. I assume that users who use other languages have the same problem.

Edited by Willy2

Share this post


Link to post
Share on other sites

- I regularly use a program called "Clonespy" which is made in Germany. This program also recognizes - like DF - that the dutch name of the folder "C:\Users" should be displayed as "Gebruikers". But Clonespy doesn't have the sorting problem as described above. When the program displays a list with sorted folder names, it correctly places the folder "Gebruikers" between "GameHouse Games" and "Geluidsfragmenten".

 

See this screenshot:

https://1drv.ms/u/s!AluvxwylJSzygRZk92SzDknykOKd

 

Clonespy:

http://www.clonespy.com/

Edited by Willy2

Share this post


Link to post
Share on other sites

- The behaviour of moving files to the end of the drive, as described in post #39 in this thread, also happens when I use a different method of moving files towards the end of the drive. I.e. when I use the "Defrag" options. (See picture in the weblink).

 

https://1drv.ms/i/s!AluvxwylJSzygRe-gJTpLIeZ6iq1

Share this post


Link to post
Share on other sites

- Took a look at all my reported bugs and I think that the issue mentioned in post #39 is the worst bug in the program code and I think it has therefore the highest priority on the list of bugs.

 

(Yes, I keep nagging)

Share this post


Link to post
Share on other sites

- Came across another odd thing. Sometimes the DF drivemap fails to correctly show which spots on a drive are and aren't occupied by files.

 

See the picture (weblink) for an example.

- The DF drivemap thinks that the yellow blocks contain files but when I click on of the yellow blocks, DF reports "No files found".

- DF also makes another error. When I click on the black blocks then DF reports that one or more files are stored in that particular block. But the DF drivemap tells another story, the drive map says that these blocks don't contain any files at all. These blocks then show up in white.

 

(In the picture I only changed the color of a few blocks - eleven in total - in the picture to black & yellow).

 

https://1drv.ms/u/s!AluvxwylJSzygRiMsAXoXiBgHl31

Share this post


Link to post
Share on other sites

- Found another small bug in DF. The user is able to click on a place on the drivemap. If there're files placed in that particular spot then DF will list those files that are located there. But then the file list fails to give an indication on how the list is sorted. There's no Arrow head displayed in one of the headers of the file list. In this one particular case the program code forgets to make the arrowhead show up.

 

See also the picture in the weblink:

https://1drv.ms/i/s!AluvxwylJSzygRnD2AT08SavZGV9

 

Only when I sort that list (for the 1st time) an Arrow head will show up. Every time after that I sort the file list then that Arrow head keeps showing up (as it should).

Share this post


Link to post
Share on other sites

- The sub-routines used for displaying the filemap also need to be improved. I know that on some places on my HD file(s) is/are located/placed. But in spite of hitting "Analyze" multiple times DF simply fails to let those files show up in the filemap. Even restarting the program won't fix this problem.

 

- DF also still thinks that in some places/locations files are located but when I move the (mouse-) to such a place then DF reports "No files found" (or something similar). And even restarting the program won't fix this problem either.

 

- Seems that filemap info is located somewhere in memory on on the HD and DF fails to erase that info. Perhaps DF has an "internal" variable that tells DF what the current state is of the filemap. Or perhaps DF overlooks certain categories of files.

- Perhaps DF needs an extra option/switch that will tell DF whether or not to (fully) re-examine/analyze the drive, with a new fresh re-building up of the filemap.

Share this post


Link to post
Share on other sites

- Another thing that needs to be improved in the next version of DF: DF doesn't Always take into account that I have the Taskbar on the left hand side of the screen. This odd behaviour occurs when I want to shrink DF to its previous (non maximized) size. Then the left hand part of the GUI is "hiding" under the Task Bar.

Share this post


Link to post
Share on other sites

- I came across the problem (as described above) again and made a screenshot. See attachment.

- Does this happen as well when the Task bar is on the top of the (visible) screen and at other places of the (visible) screen ?

post-21462-0-72076600-1500638389_thumb.png

Share this post


Link to post
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

×