q1
On ntfs fresh formatted drives, no files on them, diskmap shows 2 compact unmovable files/zones. First big file/zone is
MFT+reserved area. The second is metadata(as PerfectDisk says). Mydefrag process both with ReclaimMFTzone?
q2
- 1 hdd, 2 active partitions each with his OS. If booting from first OS can defragment ALL files from the other
partition with windows files(pagefile, hiberfile, dat, etc).
- Or boot from BartPe to defrag the windows drive.
q3,4,5
The Application Programming Interface (API) of the defragmentation library is the same on all Windows
versions
Same on all, same on NT's, or same on w2k/XP/2k3/etc ?
If same on all, on w95/98/ME folders CAN be moved on fat32.
Back compatibility mean: if defraggers can move folders on w98's API/library/system, the ones included in w2k should
be able to move them the same. I suspect some undocumented functions can do the job.
Why? Because Raxco's PerfectDisk is able to move folders on fat32 drives in offline mode under windows by closing all
open handles to the drive.
So, the API can do it, in special conditions, somehow, by locking the drive until offline defragmentation ends.
My feeling is the API refuses to move folders because some deep conditions are not satisfied by previous actions or
executed functions at driver/filesystem level.
I'll try to trace the calls on built-in defrag and SpeedDisk on w98 and w2k built-in defrag/Raxco/Mydefrag. Lot of
time to spent. Who knows? Some diferences founded this way can make the light.
The other questions were about the diferences between a script made by you and the same script without /*SPACEHOGS*/.
The script with /*SPACEHOGS*/, make excludes in files selected previously.
The macro is to pass to program the -u additions for spacehogs from the commandline.
Without -u params in the commandline changes are made by the "unused" /*SPACEHOGS*/.
I've noticed the modified behaviour when runned un a slow computer, the macro forces previous selected files to exclude
the spacehogs without the exclusion to be present in the previous file selection.
The simple presence of the macro in script body seems to do the exclusion otherwise necesary in previous selections.
Am I correct?
If this is correct, it is a big step to solve "my problem" spreaded on this forum.
A macro-keyword able to exclude masks by default from previous selections(like /*SPACEHOGS*/ does) and named
/*ENDOFDRIVE*/ can select files and exclude them from previous selections (including spacehogs) by default.
With a new /*ENDOFDRIVE*/ macro, stronger than /*SPACEHOGS*/, files can be selected to go to the end, eliminating the
hasle to build complex "* and not..." for n-1 rules.
Pushing things even far, the built-in list of spacehogs can migrate to a text file, in the mydefrag folder, with
spacehogs on separate lines or same line with separators.
This file, spacehogs.txt can have a sister named endofdrive.txt wich can contain another list of masks to place to the
end of drive.
If those files are present in mydefrag folder, and their contents is not nul, script compiler can add/process by
default the spacehog+endofdrive selections and substract mentioned files from previous rules.
So anyone who creates a script and make 1 selectionrule, can have by default 2 more rules by those 2 files content.
People who don't need to optimize with /*ENDOFDRIVE*/ and /*SPACEHOGS*/ can delete the macros or empty/delete the
files.
_________
Just to complete the idea I will put next the answer included in reply to the other topic
http://www.kessels.com/forum/index.php?topic=1559.msg9588#msg9588___________
By enforcing the behaviour of endofdrive over spacehogs and both to have specific position on drive (fastzone,
spacehogs, freespace, endofdrive) you can avoid complex excludes in rules for the fast zone.
Another advantage can be less file moves when making place in the fast zone.
The general act of MyDefrag is to solve selected files for a zone and then solve next selection/zone.
When process zone 1 and find a file who don't fit here, it moves it to first gap. Am I right?
I assume he don't know where to put it because the next rules are not parsed yet. Right?
If a script has 4 rules, some files are moved by 1,2,3 and in the end by 4.
If the program read all the rules in script, when vacate a file from z1 it can place it directly to his zone (z3 for
example). If the space in z3 fot this file is also taken by a file (belonging to z2 for ex) to suspend first move and
vacate new file to z2.
This is recursive but somehow quick convergent. For sure this result in less file movement.
That's why I say: after drive analysis, all declared zones for placement must be known. To know how to better vacate
files.
The reverse method is to read all the rules and to process first files who go to the end, calculate free space, process
spacehogs and after that sort remaining files for the fast zones of drive.
Let me explain.
Most of drives have tens-hundreds filetypes who
- need low speed,
- are big
- many
- never modified
In this category I put archives, music, movies, pictures, txt, pdf, inf... etc
This files can take from 20 to 80% of drive space and every ata drive has at the end enough speed(> 4Mib/sec) to allow
them to be read without problems. Those files can be also acessed 1/day but still no need to mix them with files
acessed thousand times/day to the fast zones of the drive.
The sortbyacess rule can't count the total hits. Just the time elapsed from last acess.
Two files acessed in the last 1 day can have few hits (mp3 file) or milions of hits (dat file).
This is where I wish to make the selection possible.
By acess time they can go to zone1, luckyly to spacehogs. By my wish some 1day files can go to end and stay here
whatever.
If the first action is to move those files to the end, then the spacehogs and exclude them (with as simple as possible
selection type) from other possible selections will free the space in the fast zones (this allow easy fill with
necesary files), reduce some useless movements to vacate and also minimise the needed ram for processing (by keeping
just remaining files to process for fast zones) .
Like renovation of a new house and firstly put carpets, wall painting, place furnitures and after that throwing the
garbage and old stuff to the box on the keep room.
My fixation is to get/clean the garbage and put it in a box far away, move the old stuff to keep in a separate room
and when I have full place to move, beautify the rooms without the need to move unused boxes from here to there to put
a chair and again to put table or to put my wife to hold it until I finish the placement.
I admit, this is somehow the viceversa (partial) of what mydefrag do at this moment.
In my opinion the simplest method after analise of drive is to:
- read a file with endofdrive(EOD) and spacehogs(SH) masks
- select-cut the EOD files from the list and place them
- calculate the free space before the EOD files to get the last sector of SH zone(+ 10÷30% to compensate unmovables)
- select-cut the SH files from the list and place them
< now the length of the list get smaller without EOD&SH files and has only the "fast files" >
- place files the "fast files" by the rules in the script
But, as a middle solution, when placing files begining with first sectors of the drive, when a file who need to be
moved to a later zone matching the next rules, a good idea is to suspend active zone and vacate this file to his zone
and then resume the active zone.
At least do that with EOD & SH files!
_________
about your reply at
http://www.kessels.com/forum/index.php?topic=1559.msg9588#msg9588___________
q1
My time is zero compared with the time you put to make this program better or answer to our questions.
Making what we think is right motivate the time spent to do it.
As long my ideas are not rejected, I can explain and rafinate them.
I think they are good enough as they come from long observations of the SpeedDisk's behaviour.
q2
Declared before just to be known by next rules.
I explained how rules can be tricked for SortByLastAccess without precise selection for EOD&SH files.
To avoid "mistakes" the EOD & SH rules must be stronger than other selections, and to free the fast zone they should
have bigger priority.
The current paradigm, without some fix from you, will force the repetition of "and not(*lot of masks*)" to be present
in each of (n-1)rules. Before, I explained how I think the fix can be done (in script declared once or in external
file).
q3
The scripting has keywords. 'Select' is one of them. 'Select1', 'Select2' can be labels for later selections.
Or to make selections inline with + - ?
Just an idea!
My favourite programming language is unable to read/write unicode files, will make only commandline, no gui dos like
programs and for sure can't solve the problems for mydefrag or usual users (it will restrict the flexibility).
I can make just an program who read some ini files to produce another script to be used by mydefrag.
This is the longer way.
The short way is for Mydefrag to have built-in gui for make the config for each and save it in the root of each drive;
Or to have a simplified way to make rules in the script as I try so hard to explain.
True, my extra program can read hundred of selections and repeat them in the generated myd script. Bad idea because the lines can be much longer the mydefrag can read perhaps.
Or
The script wich has /*ENDOFDRIVE*/ to read the lines from 'eod.txt' and similar for /*SPACEHOGS*/ with 'SH.txt'. Better I say because this reuse the masks in every generated script by one or two macro/keywords in script body.
q4
Predefined/prioritary zones are very good. They separate the files in fast/slow zones and by deleting the macro/keyword from script this zones will not be used.
q5
Slow/Fast Optimize scripts has 5 zones not counting freespace zones. Pretty close to 8 wich has the endofdrive zone.
Spacehogs go just before the big free space. Endofdrive files go after the big free space, at the very end of drive.
q6
True if little free space. But zones can be processed in any order as mydefrag really can write anywhere in the free space on drive.
If first rule places files at some offset of the drive, future rules will not be able to place files before this offset point. Only after or in strange positions!
