Jump to content

Shaggie

Experienced Members
  • Posts

    14
  • Joined

  • Last visited

Reputation

0 Neutral
  1. I can't believe that it is over a full year and this still hasn't been fixed. Very disappointed! I am still experiencing this horrible problematic bug on many PCs. Have they abandoned defraggler due to SSDs becoming more prevalent?
  2. After, retrying moving the files in the "locked" block several times I was finally able to get it past the first "block", but it is still stuck at 0%, and I haven't been able to get it past the sixth or seventh "block". So far I have gotten it to go further by forcing it to move all files in the block it got stuck on to the end of the drive, but that only gets me so far and it often resets next time I start the defrag and it doesn't make it as far. I am currently running defraggler from the recovery console to avoid files being locked, but I am still having the same issue. Please note that "block" is not meant to refer to any standard drive storage grouping. Instead it is just the visual grouping of files based on the setting mentioned above. Is there any analysis I could do to help identify the problem so it could be eliminated for all users?
  3. The latest version of defraggler will not get past 0% on this one laptop I have. Specifically, it is the first "block" it will not get out of (1 wide, 3 high). I tried moving the files in that block to the end of the disk but was left with some un-movable files, some due to access denied (sys vol info files), and the rest were files that end with ":wofcompresseddata". I suspect that defraggler is not handling these correctly and is therefore commuting halt trying to move them even though it can't. Please let me know. Thank you.
  4. It seemed like in previous versions this worked to move all of the files I selected under "Move only selected file types" to the end of the drive, however they were left fragmented, and then still fully defragment the remaining files. With the latest version of defraggler, it no longer fully defragments any files when set this way. It actually causes worse fragmentation than before. The reason I occasionally do this is to try to move the files that are automatically modified extremely often after the files that are rarely changed so as to reduce the fragmentation caused when they do change and to reduce the defragmentation time required. What I do is to run two passes, the second with that option off so it defragments those files that are often modified, but leaves them after all the other files. The idea is that doing this every few months will reduce the time required for a regular defragmentation pass. It is possible that it simply appeared to work for me before, however, since the option is there, I believe that it should work. Please tell me that this will be fixed soon. If you need any information, please let me know. Thanks, Shaggie
  5. I think it would be beneficial to have an option to move specific files, similar to "move to end of disk", to after all other files, without a size limitation. This would allow users to specify files to put after everything else that are known to often change and therefore cause defraggler to move other unchanged files when defragmenting. It would speed up future defragmentations by rarely ever having to move unchanged files. I would also like to see this have the ability to control the sort order of the files being placed after all other files as some files may grow wildly in size (such as the tempdb.mdf and templog.ldf files in SQL server) and should probably go after the other files so that the drive head does not have to move far to access the different parts of these files.
  6. What you say makes sense. I would think however that if defraggler did handle these files then it would eliminate a lot of posts about this kind of thing, either specifically or generically. What I was thinking about when mentioning that it causes other files to be fragmented is that it typically moves large files into the area of unmovable files when there are plenty of small files on the drive that could go there without being fragmented. Anyway, thanks to all for the information.
  7. Yes I see, however defraggler does not really ignore them as I can see them in the drive map, and Microsoft themselves say these files can be defragmented. I wouldn't mind as much if leaving them didn't cause other files to be fragmented. What seems to happen is that defraggler decides to map a file to a section of the hard drive, however that section contains one or more of these files causing it to be fragmented. I do not understand why some other defragmenters can defragment these files & defraggler cannot. That being said, I still think defraggler generally does an excellent job, even better than many paid defragmenters.
  8. I tried the boot time defrag, but have not noticed any improvement in these files. It is difficult to tell since I do not see much info about what is being moved during an offline (boot time) defrag. Since a boot time defrag does not defragment all files, it can leave those in the middle of where it decides to place other files when doing an online defrag, even if these "unmoveable" files are not fragmented. It can therefore cause other files to be left fragmented during that online defrag. I have noticed this during my attempts to defragment my hard drive on Windows XP. I had to use a trial of another defragementer to eliminate this problem. I have not mentioned the name of it as I believe that is against forum policy. If it were possible to do a full defrag during an offline defrag, or these files were included in an online defrag, it would eliminate this problem. Note that http://www.piriform.com/docs/defraggler/technical-information/boot-time-defrag does not specify any of those files.
  9. According to http://msdn.microsoft.com/en-us/library/windows/desktop/aa363911(v=vs.85).aspx many system files can be defragmented, however these files such as $UsnJrnl and $ObjId do not show up in the defragmented files list. I do find them when inspecting blocks and it shows there as fragmented. That article shows them as the following: $Extend\$UsnJrnl:$J:$DATA $Extend\$UsnJrnl::$ATTRIBUTE_LIST $Extend\$UsnJrnl:$Max:$DATA $Extend\$ObjId:$O:$INDEX_ALLOCATION $Extend\$ObjId::$ATTRIBUTE_LIST $Extend\$ObjId:$O:$BITMAP I take this to mean that all of these exist in the hidden $Extend folder. I find that quite often one or more of the files listed in the article cause other files to not be defragmented as the system file(s) are stored in the middle of where defraggler has decided to place the non-system file. Is there a reason for these not showing in the listings or defragmenting them?
  10. I should have mentioned that I have 12.5GB free, and the defrag completed successfully with that option off. Here is my screenshot (it is after another attempt with the setting on even though I had already defragged completely with it off):
  11. When defragging with the latest version & the option "move large files to the end of drive during whole drive defrag" on, I get the following error: "Processing aborted due to: There is not enough space on disk." I have not yet tried it without the option on.
  12. I get the exact same thing on multiple computers, and I am using Defraggler v2.0. No matter what I try I cannot seem to get it to defragment those sections. Can anyone explain this? Shaggie
  13. I do not really think that this is a bug. I think it is just a matter of interpretation, and what they should do is change the captions to clarify this. What I mean by a matter of interpretation is it depends on what "allow fragmentation" applies to. If this is meant to apply to file fragmentation then I can see how it would seem to be working incorrectly. If, however, this is meant to apply to free space fragmentation then I believe it is working correctly. I think that Piriform should update the captions to say something like "allow free-space fragmentation" otherwise people will continue to misunderstand these options.
×
×
  • Create New...

Important Information

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