Does Defraggler still not see it if you set the pagefile back to system default settings in Windows ?
- When I set the pagefile to its default setting then DF still fails to show the pagefile in the drive map.
- I also ran SPECCY & XYplorer (https://www.xyplorer.com/) and both programs reported that I had a pagefile of ~ 8 GB (16 GB virtual memory and 8 GB physical memory ==> pagefile of 8 GB).
- I also noticed something else. Upon start up DF can defragment a number of system files. (I activated that option) The names of those files are listed for a brief moment when Windows starts. But now the list doesn't include "Pagefile.sys" (any more ??). That would suggest that DF fails to recognize the pagefile is active or present. Odd, very odd.
- I moved a whole bunch of files to the end of the drive. As a result of that at the beginning there's no place where the pagefile can beplaced without being fragmented in A LOT OF fragments. Perhaps that could push DF "off the rails" ?? Or perhaps in this case Windows simply doesn't want to create a pagefile.
Because I have seen cases where a drive was so full that Windows removed all kinds of temporary system files, including the pagefile. But on the other hand I still have some 80 GB of free diskspace. Odd, very odd.
- I made a picture of the situation on my HD. See attachment. I moved A LOT OF "spacehogs" to the end of the drive. Would such a "crowded" HD impede Windows to create a pagefile ?
- Did another search (with DF) to find the pagefile (also on the other drives) but to no avail.
Deleted.
- 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 ?
- 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
- 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)
- 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.
- 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".
- 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.
Post removed.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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).
- 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)
- 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)