We should forget about moving directories on FAT32. Microsoft just isn't interested in making FAT32 directories movable.

But "Idle" is defined as some time period during which there is no mouse and keyboard activity, so it should not be affected by BOINC (unless BOINC keeps PC alive by simulating keystrokes or mouse movements).

[not]

Of course, math problems should be not as simple as 2*5 + 1, but more like "Solve equation 'x squared - 4 = 0' and enter your answers (separated by space)". Also, equations must be stored as image file (not html) with some distortion added to it.

Just ask new users to solve simple math problems during registration and enter their answers. How hard is this?

I think in many cases NTFS driver chooses to write near some files on partition in order to reduce free space fragmentation. So, if there are tiny unmovable files at the end of the partition, it is very much possible that NTFS will write new files in that region.

Mimarsinan, I respectfully disagree with you about the idea that fragmentation has no impact on performance. Performance degrades not because reading files is slower, but because file system is less efficient when files are fragmented (I think that's what Kasuha tried to explain). I'll explain this below.

NTFS is extent-based file system. An extent is a block of contiguous clusters of a certain file. Pointers to file are stored inside MFT, and each extent of a file is represented by [starting cluster, extent length] pair. If a file on an NTFS volume becomes fragmented enough (tens of fragments), pointers to its location inside no longer fit into MFT. In that case, an attribute called $Attribute_List is created in order to store records pointing to file's location, and old MFT record stores pointer to that $Attribute_List file. If then file becomes even more fragmented, space allocated for pointers inside $Attribute_List fills up. Then additional $Attribute_List files are created to store pointers to file.
So, for fragmented enough files, file system has to walk through MFT and all these $Attribute_List files to collect file's location and access that file. This means reading a lot of data just to access that file (if the file was unfragmented, it would be necessary to just scan one MFT record). So, things slow down irrespective of how low is SSD access time, not to mention CPU and memory overhead due to processing of all these extents.

Also, even good SSD suffer from poor random write performance (because NAND flash block have to be erased when writing to that block). Consolidating free space on file system level (doen't matter how free space is distributed inside SSD itself) will force OS to write in larger chunks (because it won't have to write all over tiny free space gaps).

As far as I know, current position where standard scripts move MFT to is set up according to Microsoft research during which it was figured out that the disk is providing about the best performance when MFT is placed approximately at 30% of the used disk size.

Microsoft did research relocating the MFT to avoid corruption, not performance.  By locating the file approximately 30% inside the disk, file corruption was reduced over 90%.  I never knew about the purpose of this placement until I heard a Microsoft engineer explain it at a local conference for IT professionals.  He is said it was one of the most impactful biggest and easiest fixes they ever developed.  It is all about the physical disk, not the partition.  If the partition is not near the outside edge, then reliability is not an issue.
   
Of course, an uncorrupted MFT does perform much better than a corrupt one.

Very interesting! So are you saying that corruption is more likely to happen on the outer edge of the disk? If so, why is this the case?

Perhaps maybe running some other script directly after a system monthly may get the frags down?

Defrag-only script should be able reduce number of frags seen by other defragmenters.

Since this is a backup file, it is most likely huge, so it is normal that defrag takes so long. I would recommend to exclude this file from being processed by MyDefrag.

Since this is a backup file, it is most likely huge, so it is normal that defrag takes so long. I would recommend to exclude this file from being processed by MyDefrag.

Another option is to use HDView (http://home.arcor-online.de/alexander.freudenberg/dev_en.htm#HDView) and select Tools -> Find -> Type "Usn" (without quotes) -> double click on the file that was found.
HDView gives a lot of other useful info as well.
Here's what I got:

I would suggest using Daily script since Monthly scripts takes so long.

Hi does anyone know if the problem with deleting restore ports was fixed in windows 7? I just upgraded and really need to know please

The problem was not fixed. I am using Windows 7, and it still deletes System Restore files during defrag.

What is this intended to accomplish exactly? Is it for preventing it from interfering during a scan, or at all times? Just in between these unfinished scans?

Large files exept for pagefile and hiberfil should NEVER be on a sytsem partition.

About movies, music and photos, I agree. But I think huge database files, virtual machine files, etc. should remain on system partition because it's faster.

WEI disables Superfetch only if WEI score is higher than 6.0 or so (i.e. storage is fast enough so Superfetch is not very beneficial).