Is there a reason code for "file can't be moved"?

[DWalker59]

I like MyDefrag a lot, but I have a question.  As part of cleaning up my Mom's computer, I ran MyDefrag 4.0b11 on it. 

There were dozens of files on her C drive that "couldn't be moved".  For example:

2            11,525       3  C:\Install\Drivers\_Archive\Asus M2NPV-VM Motherboard\Drivers\Audio-Win2000\32bit\SM_Comn\Help\Dutch\cpsimp.chm

This is a compiled Help file in the Dutch subfolder of an old driver that I had moved to a folder named Archive.  It is a driver for a Windows 2000 system, and her system is Windows XP, so this file won't ever be used.  There are lots of similar files in a couple of different folders such as .htm files that are part of the French help system for a program that isn't running.  But, some of the files in the same folders were moved.  Some of these are marked read-only, but most of them, like the file I mentioned above, are not read-only, not marked Hidden, and not marked System.

When the Windows API refuses to move a file, does your program get a reason code?  Or does the API just say "no thanks"?  I am curious because I don't see any reason why these files should not be movable.  I * know* the files are not in use.

Second question:  When the log says "These files are fragmented", does that mean they are still fragmented after MyDefrag?  It appears that they are, but WHY are they still fragmented?  The script that I ran should have defragmented them; all of the FileActions are "SortByName" or "SortByLastAccess".

Thanks.

David Walker

[gemisigo]

Second question:  When the log says "These files are fragmented", does that mean they are still fragmented after MyDefrag?  It appears that they are, but WHY are they still fragmented?  The script that I ran should have defragmented them; all of the FileActions are "SortByName" or "SortByLastAccess".

The manual says that "All the sorting fileactions will create fragments." That means all the SortThing fileactions do fragment files if it is necessary to fit them into a gap. That is normal.

Regarding your first question, that is something I would like to know, too.

[jeroen]

This is a compiled Help file in the Dutch subfolder of an old driver that I had moved to a folder named Archive.

The most common reason for unmovable files is that MyDefrag is running in a userid that does not have full permissions for the files. See the properties of a file, the "security" tab. Please note that on Windows it is possible for a userid with full administrator permissions not to have access to all files.

When the Windows API refuses to move a file, does your program get a reason code?

Yes, but the errorcode is not very informative and basically useless. It only says that a file was unmovable, not *why" a file is unmovable. You can see the errorcodes in your "C:\Program Files\MyDefrag v4.0b11\MyDefrag.debuglog" file.

Second question:  When the log says "These files are fragmented", does that mean they are still fragmented after MyDefrag?

Yes, the list is created after the script has finished.

WHY are they still fragmented?

For more information see Why is my disk not perfectly optimized?

[DWalker59]

In my case, I'm sure the user had full permission for those files, but I'll check again anyway.  There's no problem with the API moving read-only or hidden or system files, as long as the user has permission, is there?

As for the disk not being perfectly optimized, I know all of that, but I was left with a *whole lot* of yellow files even though all of the defrags should have consolidated these files into one piece each.

[jeroen]

There's no problem with the API moving read-only or hidden or system files, as long as the user has permission, is there?

Exactly right, MyDefrag has no problem moving read-only or hidden or system files as long as the user has full permissions.

[DWalker59]

"The manual says that "All the sorting fileactions will create fragments." That means all the SortThing fileactions do fragment files if it is necessary to fit them into a gap. That is normal."

OK, but this is slightly confusing when you read it along with the explanation of Defragment, which says:

"MyDefrag will automatically defragment an item when it moves the item. Some of the other FileActions will always move all items, for example the "SortByName" action. In those cases it is a waste of time to also use Defragment."

THAT explanation is a little weird.  If you want each file in one piece, then maybe it is not a waste of time to use Defragment after SortByxxx -- although Defragment may undo what you have done.  The documentation seems like it contradicts itself a little bit.

How do we get files defragmented (each file in one piece) and also sorted by last access, for example, without gaps between the files?  (At least, without a gap between each file?  A few gaps don't bother me, but thousands of gaps, one after each file, seems counterproductive.) 

Is there a way to do this?  THAT arrangement sounds like the ONLY logical way to defragment a disk anyway!!!

Thanks.  I'm sorry to be so persistent, but I want to understand what's going on.

[Darlis]

@jeroen: Here's a new idea for your wish list:
Change the sorting statements into SortByXXX(Ascending/Descending, yes/no), where yes means "fragment file to fill gaps" and no "do not fragment". And maybe do the same for MoveDownFill(yes/no).

This should solve DWalker59s problem.

[jeroen]

The documentation seems like it contradicts itself a little bit.

Feel free to use the Defragment fileaction just after a SortBy fileaction. But the result will be a slower disk with a lot of small gaps

How do we get files defragmented (each file in one piece) and also sorted by last access, for example, without gaps between the files?

That is exactly what MyDefrag does for the vast majority of files. From the manual: "All the sorting fileactions will create fragments. They move all the data to the beginning of the zone in the specified order, but there may be some unmovable files in the way. Instead of leaving gaps (if a file doesn't fit between the last file and the unmovable file), the program will "wrap" the file around the unmovable file by splitting it into fragments. This may seem strange for a defragmenter, but the fragments are aligned and the impact on performance is therefore very small. Skipping the unmovable file and leaving a gap would make all the files slower that are above the gap, because they would then be placed at a slightly slower part of the harddisk than they need to be. Also, gaps promote fragmentation, it is best to have as few gaps as possible. The fragments look terrible on the screen and in the statistics, but they are there to make your harddisk faster."

[jeroen]

Change the sorting statements into SortByXXX(Ascending/Descending, yes/no), where yes means "fragment file to fill gaps" and no "do not fragment". And maybe do the same for MoveDownFill(yes/no).

Thank you very much for sharing your idea, I appreciate it. But I'm afraid I will not be adding such an option. "The fragments look terrible on the screen and in the statistics, but they are there to make your harddisk faster."

[gemisigo]

How do we get files defragmented (each file in one piece) and also sorted by last access, for example, without gaps between the files?  (At least, without a gap between each file?  A few gaps don't bother me, but thousands of gaps, one after each file, seems counterproductive.) 

Is there a way to do this?  THAT arrangement sounds like the ONLY logical way to defragment a disk anyway!!!

Thanks.  I'm sorry to be so persistent, but I want to understand what's going on.

The point is that we want our disks to perform better. Defragmenting only will do a half job. SortByXXX-es will only fragment the files if they cannot fit them in a gap. Moving the files further towards the end of the disk will result in a greater performance penalty than having them in a few (but aligned) fragment placed as close to the start as possible. That is why "optimizing" the disk will most of the times result in fragmented files. And and optimized disk performs better than a defragmented (only) one.

Change the sorting statements into SortByXXX(Ascending/Descending, yes/no), where yes means "fragment file to fill gaps" and no "do not fragment". And maybe do the same for MoveDownFill(yes/no).

Thank you very much for sharing your idea, I appreciate it. But I'm afraid I will not be adding such an option. "The fragments look terrible on the screen and in the statistics, but they are there to make your harddisk faster."

IMHO there is already enough different methods to intentionally slow down the disk, there is no need to equip fileactions with parameters that makes them less efficient.