A. I have two (logical) drives C: and D: and it seems DF behaves weird. I did the following:
1. Started DF.
2. Analyzed drive C: and there were no defragmented files.
3. Analyzed drive D: and then were 3 defragmented files.
4. Now, when I returned to drive C: then DF didn't update the view of the list of defragmented files. DF still displays the file list of drive D:
See attachment.
This weird behaviour occurs only before I defrag - at least - one drive. And this behaviour didn't occur in previous versions of DF.
B. When are the Piriform folks going to fix the ""Defrag free space"" bug/issue ???? This bug has been around since DF v1.18 and was NEVER fixed ! It's just a matter of swapping two pointers !!!
When I want to perform ""Defrag Free Space"" then DF v2.04 actually performs a ""Defrag Free Space (Allowing Extra Defragmentation)"" and when I want to perform a "Defrag Free Space (allowing fragmentation)"" then DF v2.04 actually performs a ""Defrag Free Space"".
Here're two more bugs in the GUI of Defraggler. In two cases the user is asked for confirmation. But no matter what language I choose the language always is dutch ("Ja" and "Nee") instead of e.g. "Yes" and "No" (english), "Ja" and "Nein" (german) or ""Oui"" or "Non" (french).
See the pictures in the attachment for more details. In the pictures I choose the DF language to be english.
1. When I change the language then DF "forgets" to ""translate"" three strings:
-- "Check for updates..." on the bottom left hand side,
-- "Drive map" on top of the filelist,
-- "Online help" on the bottom right hand side.
The only way to get these strings translated is to restart the program. So, these three stings are left out of the, what I would call, "language refresh screen"-(sub-)routine.
2. On the bottom right hand side of the screen ("Online help"): When the user rolls through one of the scroll down menus then on the left hand side bottom of the main screen (pane ?) an extra explanation is displayed. Then the strings "Check for updates..." and "Online help" disappear temporarily. But when I select e.g "Settings", "options..." then only the top, say 20% of the words "Online help" are displayed. And this distorted view pops up as well when the user selects a number of other menu items:
-- "Drive legend" (in "Help")
-- "Drive map" (in "Settings")
-- "Defrag File" (under "Action")
When I choose one of the other DF menu-items (e.g. "Help", "About...") then this distorted view disappears.
See the encircled words in the three pictures in the attachments for more details.
Bug in DF v2.05: DF still forgets to translate the word ""drive map"" on top of the filelist when I change the language. See also post #4 in this thread. It remains ""Schijfkaart"" (dutch for ""drive map"") even in german, english, danish or polish. I need to restart the program to get the proper language string displayed.
Note: I write this post on a friend's PC with Win 7 64bit installed. But this shouldn't be a OS related bug.
Perhaps I need to elaborate more regarding the bug described in post #2, because that particular bug hasn't been fixed (yet?). My native tongue is dutch so the language of Windows I use is, of course, dutch. When I change the language from english to e.g. danish, german, spanish or french, those two choices ("Yes" and "No") are still in dutch ("Ja"and "Nee").
This suggests that DF uses for these two particular dialogs a sub-routine/API from Windows itself, instead of using a sub-routine within DF. Then Windows notices that the language used on my computer is dutch and then displays those two dutch texts no matter what language has been selected in DF. Or perhaps Df uses the proper Windows API but it has the wrong entry parameters ? Can anyone replicate this bug ? DennisD ? Aethec ? ........ ?
I came across another bug in DF (v2.11): Again, one word doesn't get translated when I change the language. It's the word "Color" in the tab "Drive map". I need to restart DF to get this word translated/string replaced. Seems DF doesn't read the proper word from the appropriate language file when I change the language. But DF does read it when DF (re-)starts.
The attachment shows this word after I changed the language from dutch to english. The dutch word "Kleur" should be replaced by "Color" but it wasn't. The word "Kleur" continues to be displayed whereas all the other text is changed/translated into english.
Came across other translation related bugs in DF. Two words don't get translated inmediately after I change the language from e.g. english to dutch:
1. I need to click on the drivemap to get the string "[File entry"] translated to the dutch string "[Mapwaarde]".
2. The word "Highlighted" also doesn't get translated. I need to close that tab and click on block that represents a piece of a file to re-open that "Highlighted" tab. Then the dutch translation string shows up.
"Bestandsmap" is dutch for "Directory File. It's clear DF pulls up/tries to pull up the dutch name for this filetype. And in about 99% (100% ????) of the cases it pulls up the right dutch name. E.g. When DF comes across a defragmented "*.MOF" file, DF displays the dutch text "MOF-bestand" (= "MOF-file" in english) and not the english text "MOF-file". Thumbs up for DF !!!
When I change the language from dutch to english then DF still pulls up the dutch filetype names. So, it seems the file type name is pulled up from one's Operating System and the file type name is not stored in DF itself.
Up to this point I have nothing to complain about.
But when a file doens't have an extension, DF still marks that file as a (defragmented) "Directory file" (dutch: "Bestandsmap") but it should be obvious that when this file doesn't have the "Directory" attribute set, it shouldn't be marked as such. It should be named "bestand" (=file).
See also the picture in the attachment. E.g. the file named "Search[4]" is a file while at the same time the file named "{1778657e-35dd-......" is a folder. But DF marks both files "Bestandsmap" (=Filedirectory).
I DO think this is a flaw big enough to call this a BUG !!!!
When I let DF (v2.16) let do a search for a (defragmented) file then DF closes the "Search" tab and opens the "File list" tab that only shows the fragmented files !!! Instead of showing the files that DF found in the "Seach" tab. Now I have to re-open the "Search" tab again. Only then DF shows the files DF found (both defragmented & fragmented).
I need to add more info regarding this bug. And it certainly is a BUG !!!!
The bug, as described above in the previous post, only happens when DF does a "Search" for the first time after the user has started the program. The second time DF behaves as it should.
This can be one of those "Minor bug fixes" the developers are talking about. Needs to be improved !!!!
I took the following steps and I noticed DF's behaviour changed:
1. - Open Defraggler and let the program analyze one disk.
2. - Reduce the size of DF the GUI window from "Maximized" (full screen) to say 60% of the screen. (it happens also when the DF GUI window is maximized. One then has to enlarge the column's width.) As a result the columns "Last Modified" & "Path" are no longer shown in the filelist in the DF GUI window.
3. - Click on each column header (e.g. "Path" or "File name") once to sort the info in that column. DF behaves as it should. E.g. when I click on "Path" (as many times as I want) then the column "Path" and the info in that column remains visible in the DF GUI window.
4. - Now set DF to work. Select a number of files and let the program defrag those files and after that the behaviour of DF changes.
5. - Whenever I click on any column header to sort the info in that column the GUI "freaks out". E.g. when I click on "Path" (situation as in the 1st screenshot) to sort that column, the column "Path" disappears out of the visible part of the DF GUI window and the entire column "Filename" shows up in the DF GUI window, in the left hand side of the DF GUI window. (See 2nd screenshot). And that happens everytime I click on a columnheader to sort the info in that column. It even happens when I click on the "Filename" header when that header/column is only partially visible in the DF GUI window. This behaviour is VERY confusing/annoying for a user and I consider it to be a bug. Because it doesn't happen when I haven't defragmented any files.
In other words: when I click on the "Path" column header (to sort the info) the GUI changes from screenshot #1 to screenshot #2.
2. - Tick the box called "Move large files ........... "
3. - Select a number of other options.
4. - Now put DF to work with the option "Defrag (whole drive)".
5. - Select "Settings", "Options", "Defrag" again, while DF is busy. The entire tab shows up greyed out (because DF is busy) but nonetheless the tab also shows which options have been selected. (I like that feature). So far, so good.
6. - The small bug is that the box in front of the option "Move large files ............ " shows up greyed out, but UNTICKED as well !!! (Remember, I ticked the box in step 2 !!!!)
- I tried to reduce the amount of folders under the option "Move only selected folders/........... " ("Defrag" tab in the "Options" window). But after I removed three folders and restarted DF those folders keep popping up. I simply can;t get rid of them.
Is this a bug in DF v2.19 or is some odd registry setting "wreaking havoc" ?
I added the "Defraggler.ini" file to this post for more info.
Nope. DF v2.19 makes the same mistake again. I was fiddling around with the program (can't recall all the things I did and in which sequence I did those things). But the endresult was that when I opened the "Exclude" tab ("Settings", "Options") three folders were listed more than once.
I also noticed that the program doesn't sort the "MoveToDriveEnd=......... " folders. However, the "Excluded=........... " folders are sorted. Odd. Looks like this DF program code needs some decent improvements.
For more details, see also the *.zip file in the attachment.
The folder "C:\Windows" was listed 4 times in "Exclude". I removed 3 of those 4 lines (using the GUI), closed DF. But in "Defraggler.ini" those 4 lines remained. So, DF somehow fails to remove those lines in the *.ini file.
Update: I told DF to store the settings in the registry and now (it seems) this odd behaviour doesn't show up anymore.