DF v2.20 still has another bug. Take the following steps:
- Make sure DF stores the settings in the file "Defraggler.ini".
- Add a number of folders to the list of folders that should be moved to the end of the drive. (Settings, Options, Defrag, Files/Folders).
- Now delete a number folders from that same menu.
- Close & restart DF. After that the list with folders (to be moved towards the end of the drive) will show multiple instances of the same folder. See the attachment for an example.
Side note: thx for new title. I love you (like a man loves a fine cigar, I mean, not romantically)
- More bugs in DF v2.20: The entries mentioned in reply #1 of this thread don't get sorted at all.
(A pity I don't smoke. Although I love to have good glass of (dutch (!!!)) beer, not that horrible stuff that the english call "beer")
Gave it another try and DF failed miserably. I ran DF v2.20 with the settings that are attached to this post and DF did NOTHING but told me (after say 15 to 20 minutes) that it would take 17 hours to complete the entire task. I wasn't able to sit behind my laptop that long, so I aborted the program.
I excluded ALL the main folders on my C: drive except for one ("C:\MicroSD") that was filled with only *.mp3 files (over 5200 *.mp3 files) . Based on the settings of DF I would have thought that DF would come to the conclusion that not a single file had to be moved and would be finished after say 3 to 5 minutes, but alas it didn't happen. It told me, as mentioned before, that it would take 17 hours.
I must add to my previous post that I used the "Defrag Freespace" option.
Found another bug in DF (v2.21). At least, DF did something I didn't expect to happen. (See the attached screenshots).
- I wanted to change the content of "Files/Folders" to "C:\MicroSD". So, I clicked on "Edit" (blue Arrow, 1st screenshot) and selected "All Files" (Red Arrow, 2nd screenshot) instead of "File Types". Now the box behind "File Types" (Blue Arrow, 2nd screenshot) was greyed out. So far, so good. But when I returned to the other menu (1st screenshot) DF continued to say (Under "Files\Folders") "C:\MicroSD\*.mp3" instead of "C:\MicroSD" (what I would have expected to show up.
Another bug in DF v2.21. I re-installed the program and told it to analyze the C: drive. To my surprise three System Restore Points showed up in the file list, in spite of supposedly being excluded from showing up. See the picture in the attachment for more details.
- DF v2.21 is doing its job (a little) better than I thought it did. I told DF again to move a bunch of *.mp3 files from one folder to the end of the drive with the "Defrag whole drive" option. I aborted the defrag after say 20 minutes. From what I saw going on in the drive map in DF I thought that DF had failed miserably once more.
But when I restarted DF I noticed that the amount of *.mp3 files that were moved towards the end of the drive had increased. That suggests that the updating of the file map doesn't keep up with the changes DF makes. I think it's very likely/possible that the sub-routine that calculates the "remaining time" interferes with the moving of files and/or interferes with the updating of the drivemap.
Perhaps it's better to simply get rid of the "Remaining Time" feature all together ?? Because DF displays the name of the file that's moved and sometimes such a name keep being displayed for seconds suggesting that DF has got stuck at a certain point while at the same time DF keeps reporting that it continues to "Calculate the remaining time".
I would suggest to test DF without that subroutine that calculates the "remaining time" and see how DF fares without.
- Regarding the systemfiles of which the name start with a "$" character.
Is it the intention of the developers to let DF move those files as well ? That would make sense in one way (Can they be moved at all ??? Does Windows allow that ?? ) but then there's no way for the user to select or un-select those special files.
Because DF displays the name of the file that's moved and sometimes such a name keep being displayed for seconds suggesting that DF has got stuck at a certain point while at the same time DF keeps reporting that it continues to "Calculate the remaining time"
I wonder if this is a bug or more so a limitation in the Windows Defrag API. I've seen many defrag tools including Windows Defrag (on XP at least when it still had a drive map GUI) seemingly get stuck (not really stuck at all) on a filename of a file which is too small to take so long to move.
@Andavari: I only report what I see and have to make a guess of what's going on.
I highly doubt there's a "Defrag" API. I think it's more likely that Windows allows the user to specify to which sector a file is to be moved. But that's a guess as well.
There seems to be a "Move File" API.
http://www.fact-reviews.com/defrag/Before.aspx
The article also provides some suggestions why a "defrag file" or a "move file" could fail.
I found three (3) new bugs.
DF is able to move selected files towards the end of the drive. When DF has produced a list of files (both defragmented & unfragmented) then the user can "right-click". Then a menu shows up that includes two options to move "highlighted" or "checked" file(s) (from the file list) to the end of the drive. But these 2 "move towards the end of the drive" options have 2 bugs.
Bug #1:
- Sometimes/regularly DF fails to move ALL selected files towards the end of the drive. (or - at least - that's what it looks like when I watch the drive map). Then some files simply remain closer to the beginning of the drive. Is one or the other Windows subsystem interfering ? is responsible for causing this behaviour ?? E.g the notorious VSS sub-system ?? Or can't the GUI (drive map) of DF keep up with the "speed" with which the files are moved ?
Bug #2:
- The 2nd bug is more complicated. (And I think it's a bug). I selected & moved a bunch of files towards the end of the drive and the first part all went OK. It moved files from the area marked (more or less) by the black rectangle to (more or less) inside the blue rectangle. That's the general direction of where those files were moved to.
But then happened something I didn't like. DF started moving files from (more or less) inside the red rectangle to inside the blue rectangle.
See the picture in the attachment.
Solution: (I know that each area of a HD has a unique (sector (??), block (??)) number. Otherwise the entire organisation of a drive would be a complete mess) : If a file is to be moved to a place with a lower (unique) area (/sector/block) number and it came from a place with a higher area number then the solution is simple: Don't move the file !!!!!!! It also will save time for the "impatient" DF user.
Bug #3:
The "Analyze" button Always remains visible even when one has the "Search" feature/section open/selected. But I think that when the user has hit the "Analyze" button then DF should close the "Search" tab (if/when applicable) and (automatically) open the "File" tab of the GUI.
Another thing that could be improved: When DF is busy moving files around then the map shows which block is being moved and from where to where. These blocks then show up in a different colour. I think both the "read block" & "write block" should always be displayed in a highlighted colour. It would it easier to spot where a block is being moved to.
(Currently, my "read" block is displayed in yellow and the "write" block in green).
- Found another thing that can/must be improved. When I have maximized the GUI and then want to reduce the size of the GUI, part of the left hand side of the DF windows moves behind/is hidden behind the Task Bar (on the left hand side of my screen). I have seen this behaviour with other programs as well. (e.g. when I maximize the window for CMD.exe in Windows 7).
- Found one other annoying thing in DF that hasn't been solved. When I reduce the size of the DF GUI then the GUI is reduced (somewhat). The drive list is reduced to 2 drives (DF recognizes all 5 drives on my laptop) and the drive map is reduce to one line/row of blocks. And at the same time the visible part of the list with fragmented files has been vastly enlarged.
- At the same time - as reported in the previous post - some part of the DF GUI became invisible because the DF GUI moved to the left and the left hand part corner of the DF GUI is covered by the Task Bar (which on the left hand side of my screen).
Bug in Defraggler ???
I was fiddling with the size of the pagefile and then something horrible happened. I told Windows that I wanted no pagefile. Had to restart my system and then Defraggler tried to defrag a number of systemfiles upon start up (before the bulk of the Windows software was loaded). At that point DF got stuck when it tried to defrag the pagefile. No matter what I tried, each time I restarted my system got stuck somewhere in the very early stages of the start procedure of Windows.
I am not sure whether or not I should put the blame on DF. It could be a combination of some other things. But perhaps DF isn't able to properly handle this kind of situation.
- DF (v2.21) still has a problem with (not) showing the System Restore Points (SRPs). I told DF that I didn't want to see those SRPs in the file map but after a re-analyzing the drive those SRPs still showed up. I had to restart DF to make those changes (in-)visible in the file map.
- The option that allows the user to choose whether or not SRPs and/or Hiberfil.sys should show up in the file map, should be using different words. I consider the wording of that option to be confusing. And perhaps the entire setup of that option should be changed & improved.
- I fear the developers of Piriform won't devote too much time on improving DF anymore since an increasing % of users have a SSD in their computer.
Bug (????) in DF v2.21. Topic: "Missing" pagefile.
- I recently realized that when I run DF then the pagefile doesn't show up anymore in the drive map of DF. I changed the color of the pagefile blocks from yellow(-ish) to black and (after that) to other colors as well. But it was to no avail. The pagefile fails to show up.
- I even let DF search for the file called "Pagefile.sys" but no success there either. DF e.g. did find "Hiberfil.sys".
- I ran 2 other programs (Everything & Wiztree) and both DID find "pagefile.sys". Both programs told me that the pagefile ("pagefile.sys") was ~ 8 Gb in size. Odd, very odd.
- Would changing the settings that govern the showing of System Restore Points and "Hiberfil.sys" have an impact on whether or not the pagefile shows up in the drive map ? I could imagine that somewhere deep in DF an internal switch is triggered/reversed that prevents the pagefile from showing up.
- I also have been "fiddling" a bit with how the user wants Window 7 to handle the pagefile. Things like "no pagefile" and "fixed size for the pagefile". But I would assume that shouldn't have an impact on how DF "behaves". I still think there could/is a bug in DF (v2.21).
- I recently realized that when I run DF then the pagefile doesn't show up anymore in the drive map of DF.
hello willy2
do you mean complete defrag or file defrag? i have tested it with a few files and after df finished, the pagefile.sys shows me again as before...
w8.1 64bit
- The pagefile doesn't show up anymore in the drive map. No matter what I do. I fear this could be a bug that's hidden VERY deep in the program code.