Problem with PlaceNtfsSystemFiles

[llopez01]

Hi:

I want to suggest something new for the PlaceNtfsSystemFiles. The reason is that now, with the option Number of the "PlaceNtfsSystemFiles(DIRECTION,NUMBER)" that you added on v4.2.4 (or maybe before, I began making my scripts from v4.1.1) things are not working as supposed.

This is how I have seen PlaceNtfsSystemFiles working: it correcty begins placing system files and then marks the next disk space as "NTFS reserved". But the order of the system files was established alphabetical, and so the last file is never $MFT. Then, when I restarted my system, the previous Reserved NTFS Zone does not get reassigned.

I manage to solve this by splitting it in two zones, one for the system files without $MFT, and another with $MFT and a number for setting the reserved NTFS space. This was not perfect, because with my correction the other system files change very often and this causes the program to move $MFT most of the time I defragment the drive. So I tried to set them inverted, but strangely enough, this does not work as expected: now the reserved space is used again for the other system files, and on reboot the reserved zone gets relocated and resized because it is not contiguous to $MFT. So, I went back using the first order, not a mayor anoyance, but not as convinient as I wanted.

The suggestion is when SelectNtfsSystemFiles selects $MFT, then always position this file as the last one for PlaceNtfsSystemFiles, and then position the reserved NTFS zone after it.


Regards,
Luis José.

[jeroen]

You are mistaken. The PlaceNtfsSystemFiles() action will create a gap after the MFT, not after the last file in that zone. But MyDefrag cannot guarantee that the gap will not be used by another program for a new file, so it is not guaranteed that Windows will place the reserved zone there after a reboot. For more information see the PlaceNtfsSystemFiles manpage.

[llopez01]

You are mistaken. The PlaceNtfsSystemFiles() action will create a gap after the MFT, not after the last file in that zone. But MyDefrag cannot guarantee that the gap will not be used by another program for a new file, so it is not guaranteed that Windows will place the reserved zone there after a reboot. For more information see the PlaceNtfsSystemFiles manpage.

The gap is marked blue, and on every test that I made the program never used this space for any file. It's name is not 'Empty space', but 'Reserved NTFS zone'. I understand what you said, and yes, I tried to leave a short time from the end of the defrag to a system reboot. Every time when I only used this code (notice the explicit exclusion of the other NtfsSystemFiles), I correctly managed to get this reserved NTFS zone exacty after $MFT

  FileSelect
    SelectNtfsSystemFiles(yes) AND FileName("$MFT")
  FileActions
    PlaceNtfsSystemFiles(Ascending, MftSize * 0.300)
  FileEnd


What I mean that PlaceNtfsSystemFiles did by using only "SelectNtfsSystemFiles(yes)" is: first it placed all the NtfsSystemFiles alphabetically, and the it made the gap for the reserved NTFS zone. Check by zooming in at the place used for this files, and you will find their order is:

$AttrDef
$MFT
$Secure:$SDH:$INDEX_ALLOCATION
$Secure:$SDS:$DATA
$Secure:$SII:$INDEX_ALLOCATION
$UpCase
$Extend\$ObjId:$O:$INDEX_ALLOCATION
Reserved NTFS Zone

As you can see and check with your own system, $MFT will never be the last file, as the program is using only alphabetical order, and the Reserved NTFS Zone is always following all selected files. Whichever order you choose, $MFT is not besides a gap, and then the Reserved Zone will not get reallocated.

By using "SelectNtfsSystemFiles(yes) AND FileName("$MFT")", I managed to solve this situation: the program alocated only $MFT and then a gap. Doing this and then rebooting, my test systems marked the gap as the Reserved NTFS Zone.

Regards,
Luis José.

[jeroen]

The program shows 2 reserved areas on the screen, one is the real and actual reserved area, and the other is the new area just after the $MFT. I can only repeat that the PlaceNtfsSystemFiles() places the new area directly after the $MFT. Not after the last file in the zone. It can ofcourse only make the new area if there is enough room after the MFT.

If you don't believe me then make a detailed debuglog (see the I have a problem! page for instructions) and look for a "Creating space for the NTFS reserved area" message.

[WindHydra]

So the blue area after $MFT is not real reserved zone yet    A bit confusing.  Maybe you should remove this feature or give the zone a different name, like "designated reserved".

The MFT Reserved Zone is managed by Windows.  If $MFT is moved, Windows will reallocate the reserve to the gap right after $MFT, or to some other place if there is no gap available.