Looking for feedback on script

[testing123]

Hello everyone.  First time poster, but I've been lurking and researching in the forums for a couple months.

I really like the power of MyDefrag and the flexibility it gives you in regards to how exactly you want your volumes defragged.  I'm trying to improve boot up times, and overall performance for users at my company.  I'd classify the majority of my users as just using productivity apps like the MS Office Suite (mainly Outlook), and also a mix of SAP and Java apps in there.

With that said, I wanted to come up with a somewhat aggressive .MYD file that could be run as a screen saver and this would be the only one run for most users.  So I looked at the optimizemonthly and also some of the things written in Falcon4s script, along with the daily and weekly optimize.

It's fairly straightforward, but I also have a zone for PSTs only so they are not fragmented all over the drive.  I ended up with the below script and would like to make sure it looks fair and I'm not missing anything.  I understand that the first time this script runs, it may take a while, but each time after, I would imagine it would finish much faster.

Code:

# custom defrag script
# Agressive with logging and focus on keeping PST fragments close together.

Title('Testing Screensaver')
Description("This is the test screensaver mydefrag config")

DiskmapFlip(Yes)
# Exit when finished running.
WhenFinished(wait)
# Exit if on battery power
BatteryPower(exit)
# Kill other instances if newest one senses one already running.
OtherInstances(kill)
# Prevent turning off Monitor powersaving.
PreventPowerSaving(no)
# Set window size
WindowSize(maximized)

VolumeSelect # Select all volumes that are fixed, writable, and mounted.
Removable(no)
and Writable(yes)
and Mounted(yes)
VolumeActions
# Write the "before" statistics to the logfile.
AppendLogfile("MyDefrag.log","LogBefore")
# Delete the USN (Update Sequence Nubmer) change journal
DeleteJournal()
# Reclaim the NTFS reserved area by moving non-system files to regular diskspace.
ReclaimNtfsReservedAreas()

# Zone 1: Place the MFT and some other special NTFS files at beginning of disk.
FileSelect
# Select all the NTFS system files.
SelectNtfsSystemFiles(yes)
FileActions
SortByName(Ascending)
FileEnd

# Zone 2: Sort directories by name in ascending order.  The SortByName function also defragments.
FileSelect
Directory(yes)
FileActions
SortByName(Ascending)
FileEnd

# Zone 3: Create Zone for files used when booting, and a gap. But only if those files are under 50MB.
# Exclude PST files so they are in the next zone for potential performance
FileSelect
ImportListFromBootOptimize()
and not
(
Size(5000000,0)
or FileName("*.pst")
or FileName("*.ost")
)
FileActions
SortByImportSequence(Ascending)
MoveDownFill()
FileEnd

# Zone 4:  PSTs together and as unfragmented as possible.
FileSelect
(
FileName("*.pst")
or FileName("*.ost")
)
FileActions
Defragment(fast)
MoveDownFill()
FileEnd

# Zone 5: Will sort all files in order except the ones defined below.
  FileSelect
    not(
      Size(0,5000000)
      or (LastAccessEnabled(yes) and LastAccess(,1 month ago))
      or DirectoryName("$RECYCLE.BIN")
      or DirectoryName("RECYCLED")
      or DirectoryName("RECYCLER")
      or DirectoryName("$*")
      or DirectoryName("Downloaded Installations")
      or DirectoryName("Ehome")
      or DirectoryName("Fonts")
      or DirectoryName("Help")
      or DirectoryName("I386")
      or DirectoryName("IME")
      or DirectoryName("Installer")
      or DirectoryName("ServicePackFiles")
      or DirectoryName("SoftwareDistribution")
      or DirectoryName("Speech")
      or DirectoryName("Symbols")
      or DirectoryName("ie?updates")
      or DirectoryName("dllcache")
      or DirectoryName("Installshield Installation Information")
      or DirectoryName("System Volume Information")
      or DirectoryName("windows.old")
      or FileName("*.7z")
      or FileName("*.arj")
      or FileName("*.avi")
      or FileName("*.bak")
      or FileName("*.bup")
      or FileName("*.bz2")
      or FileName("*.cab")
      or FileName("*.chm")
      or FileName("*.dvr-ms")
      or FileName("*.gz")
      or FileName("*.ifo")
      or FileName("*.iso")
      or FileName("*.log")
      or FileName("*.lzh")
      or FileName("*.mp3")
      or FileName("*.msi")
      or FileName("*.old")
      or FileName("*.pdf")
      or FileName("*.rar")
      or FileName("*.rpm")
      or FileName("*.tar")
      or FileName("*.wav")
      or FileName("*.wmv")
      or FileName("*.vob")
      or FileName("*.z")
      or FileName("*.zip")
      )
  FileActions
    SortByName(Ascending)
FileEnd
 
# Zone 6:  The remainder of files not previously defined.
FileSelect
All
FileActions
SortByName(Ascending)
FileEnd

# Add the after statistics to the log file.
AppendLogfile("MyDefrag.log","LogAfter")
VolumeEnd

I'm also curious if I should use AddGap and MakeGap to the script.  Does this help prevent files from being relocated if you have a buffer between zones?

[MiguelMS]

Hello

I've seen the following problems:

Code:

# Exit when finished running.
WhenFinished(wait)

This will wait when finished. You have to change it to WhenFinished(exit) for MyDefrag to close.

Code:

FileSelect
SelectNtfsSystemFiles(yes)
FileActions
SortByName(Ascending)
FileEnd

The sentence PlaceNtfsSystemFiles must be used when placing NTFS System Files selected by the SelectNtfsSystemFiles sentence.

Code:

# Zone 3: Create Zone for files used when booting, and a gap. But only if those files are under 50MB.
# Exclude PST files so they are in the next zone for potential performance
FileSelect
ImportListFromBootOptimize()
and not
(
Size(5000000,0)
or FileName("*.pst")
or FileName("*.ost")
)
FileActions
SortByImportSequence(Ascending)
MoveDownFill()
FileEnd

I'm not totally sure on this one, but if you use SortByImportSequence (any SortBy sentence), it won't leave any gaps (unless required by unmovable files), so there is no need to do MoveDownFill after a SortBy sentence.

Code:

# Zone 5: Will sort all files in order except the ones defined below.
  FileSelect
    not(
(...)
      or DirectoryName("Fonts")
(...)
      )
  FileActions
    SortByName(Ascending)
FileEnd

This zone appears to select all "Windows" and "Program Files" files (among others)... This is just my opinion, but you should not exclude the Fonts folder, as fonts are used by almost every program, so they would benefit being placed near all other "Windows" and "Program Files" files.

I'm also curious if I should use AddGap and MakeGap to the script.  Does this help prevent files from being relocated if you have a buffer between zones?

If you create gaps up to a rounded position, then files of zones after a given zone may not need to be moved if the current zone grows up. Example: Your zone 3 will change often, as some files will be taken to this zone (or moved to others) when files used during boot change from time to time. If more files are moved to this zone, Zone 4 files will be moved to make room for the new files in Zone 3.

If you create a gap after Zone 3, files in Zone 4 may not need to be moved even if there are new files in zone 3.

If you create a gap after Zone 4, files in Zone 5 may not need to be moved when the PST files grow up. Right now, when PST files grow, ALL files in Zone 5 will be moved because all its files are ordered by name.


Hope this help you

[testing123]

Thanks for the feedback MiquelMS

Code:

# Exit when finished running.
WhenFinished(wait)

was actually from when I was manually running the script and wanted it to stay open after it was done..  thanks for reminding me to take it out for utilizing as a screensaver.

  I've updated Zone 1

Code:

FileSelect
SelectNtfsSystemFiles(yes)
FileActions
SortByName(Ascending)
FileEnd

  with

Code:

FileSelect
SelectNtfsSystemFiles(yes)
FileActions
PlaceNtfsSystemFiles(Ascending,MftSize * 0.05)
FileEnd

  So I believe that will be better.

MoveDownFill() is what I was using to fill in gaps in the zone after a sortbyname completed.  I've read a little more on it, and it seems unneccessary, and can actually slow it down a little bit.

I agree with you on the Fonts directory, and that it can be in the same zone as the other windows files.

I've also added gaps after each zone.  I'm doing more testing, but I understand that there is a benefit to having buffers.  It's just that after running mydefrag, and putting gaps in, MS defrag is going to really think it's fragmented.  End users could have the impression I've made it worse if they went into MS defrag.

Thanks again

[MiguelMS]

MoveDownFill() is what I was using to fill in gaps in the zone after a sortbyname completed.  I've read a little more on it, and it seems unneccessary, and can actually slow it down a little bit.

SortBy functions should place files contiguously, there should be no gaps between those files... If you see little free space gaps appearing while MyDefrag is placing files using the SortBy functions, it means that some other program is writing files there and MyDefrag has to avoid these gaps because they contains files now.

You can try closing other programs while running MyDefrag, so it's lees likely to happen.

I've also added gaps after each zone.  I'm doing more testing, but I understand that there is a benefit to having buffers.  It's just that after running mydefrag, and putting gaps in, MS defrag is going to really think it's fragmented.  End users could have the impression I've made it worse if they went into MS defrag.

Microsoft Defrag will show that free space is more fragmented (there is more than 1 gap of free space) than if all files where placed together (there would be 1 gap of free space). But that's just because it doesn't know anything about optimization or files placement at all

Microsoft Defrag will try to move around files (any of them) to close all the gaps (although it never does it completly) while it defrags files. On the other hand, MyDefrag not only defragments files but places them at the disk positions you tell it in your script. If you plan your script right, these positions will have a benefit on file access/read performance.

Sorting files by its name (and folder) has a benefit because all files that belong to the same program (think about any program in your "Program files" folder) will have its files defragmented and (more important) placed near each other. But this comes with a price. If you install a new program on your computer, next time you run MyDefrag with the same script, it will have to sort the new files and will have to move all files after the place where new files will be placed. If there is a free space gap after those files, only the files that belong to the current zone will be moved. If there are no gaps, all files after the new files will be moved.

A gap has an "almost unnoticeable" impact on performance because the beginning of a drive is always faster and a gap is pushing files a bit away from the beginning of the drive. But the benefit is that next runs of MyDefrag will be faster because it will have to move less files.

Microsoft Defrag don't ever think about all that... it just thinks "gaps are bad". With MyDefrag you (as the one who wrote the script) can think about all that things and place your files they way you want. I did it myself a few months ago, thinking about where to place files, where to place gaps... and so on http://www.mydefrag.com/forum/index.php?topic=2376.0, same as you are doing now.

Every defragger out there has its own strategy to place files and measure fragmentation, so you can't really compare them by the statistics they show, as they are calculated by different methods. If one program has just finished and tell your files are perfect, another with a different strategy will say you need to defrag. But with MyDefrag you are the one creating your own strategy... and because your strategy will be different from the other defrag programs strategies, their statistics may appear as if you need to defrag again

[poutnik]

Sorting files by its name (and folder) has a benefit because all files that belong to the same program (think about any program in your "Program files" folder) will have its files defragmented and (more important) placed near each other. But this comes with a price. If you install a new program on your computer, next time you run MyDefrag with the same script, it will have to sort the new files and will have to move all files after the place where new files will be placed. If there is a free space gap after those files, only the files that belong to the current zone will be moved. If there are no gaps, all files after the new files will be moved.

Things are not so easy.

Sorting by pathname in reality divides all files related to an application according the pathname.
It supposes access relation between files with similar pathname is much stronger than the opposite.
It is not always valid, and sometimes even reversed.

E.g. for given application AppData/Application data folders are far away from files in Program folder .
On the other hand, access relation of many files within same folder is so weak there is no need to keep them close.

[MiguelMS]

Things are not so easy.

I know, but if this is his/her first script it's a good and easy approach to start with With it he/she will get a moreless noticiable improve without having to write a complex and longer (although better) script.

Sorting by pathname in reality divides all files related to an application according the pathname.
It supposes access relation between files with similar pathname is much stronger than the opposite.
It is not always valid, and sometimes even reversed.
E.g. for given application AppData/Application data folders are far away from files in Program folder.

It's not totally perfect, of course, because that solution places together the files in the same folder (sort by pathname). For many applications, it is valid, because they have just one program files folder. But many other applications use files located somewhere else. To achieve (supposedly) best performance, not only the files in the application folder should be together, but its corresponding "Application data" folder files, its corresponding "Common files" folder files, and the Windows common DLLs (System32 DLLs or WinSxS DLLs) it may use... should be together too.

Although that approach may give the (supposedly) best performance, it has more disadvantages than the benefit you may get from it:
    - It will require a "FileSelect" block selecting the specific folders for every application in your computer. You'll have to modify your MyDefrag script everytime you install a new application on your computer.
    - Data files ("Application data" folders) are supposed to be modified when the application is used (that's why they are not supposed to be in the "Program files" corresponding folder), so placing them together with the application "Program files" folder files would make MyDefrag to always move the Application Data folder files (they probably have been modified and moved) back together with the Program files folder files (they probably have not been modified), and pushing away next "File Select" blocks files when Application Data files grow.
    - You can't place Windows DLLs or WinSxS files together with every application files that may use them, just one of the applicationes can have them placed near its files. You'll have to find a method to guess what application is the one that uses them more frecuently or something... that's just not feasible, in my opinion.

In my scripts I use the following approach:
    - First: Windows DLLs, WinSxS files and so on, relatively near the beginning of the drive. Then Windows applications files and other Windows files (excluding backups, caches, installer files and so on...). There is a small gap after this files for new files or updated files to be moved here without having to move next FileSelect blocks.
    - Second: Program files folders (excluding install or update packages files that may be in the "Program files" folder and excluding data files/folders of older applications that have its data in its program files folder). Then install or update folders. There is a small gap after this files for new files or updated files to be moved here without having to move next FileSelect blocks.
    - Third: Application data folders and previously excluded data files/folders in the Program files folder. There is a gap after this files, as they are going to be modified when applications are used.

On the other hand, access relation of many files within same folder is so weak there is no need to keep them close.

In *program files* folders the access relation of the files within the same folders is weak? I don't think so. If you exclude uninstallers, readme files or unused language files (usually small compared to other files), all other files in the same folder (DLLs, additional EXEs, help files...) are supposed to be used when the application is launched/used, so there will be a benefit from placing them together.

The relation can be weak in user documents/files folders depending on the organization method the user have, if he/she saves unrelated files in the same folder. Or files may be so big that they don't deserve the effort of placing them together or sorted (the "space-hogs" in the original MyDefrag scripts) even if they are in the same folder.

In my scripts I prefer to create separate zones for Windows folder, Program files folder (...) and user files folders. I think this way you get a better performance and can sort the program files folder if you like and not the user data folders if you don't (although I do sort them too in my "Slow" script). But if he/she has written his/her script that way, he/she may have a reason but I don't know...

[poutnik]

It's not totally perfect, of course, because that solution places together the files in the same folder (sort by pathname). For many applications, it is valid, because they have just one program files folder. But many other applications use files located somewhere else. To achieve (supposedly) best performance, not only the files in the application folder should be together, but its corresponding "Application data" folder files, its corresponding "Common files" folder files, and the Windows common DLLs (System32 DLLs or WinSxS DLLs) it may use... should be together too.

Most of possible approches has their own flaws.
One need always keep in mind if maintainence of their layout does not cost more, that is gain what they provide.

I usually divide active files into 2 groups with similar size, divided by MFT/folders zone, sometimes with small files zone

(begin of disk)
Recently accessed 1
Recently created or modified 1

MFT+$files
folders
(optionally often accessed files <64-128kB )

Recently accessed 2
Recently created or modified 2

Rest of files.

On the other hand, access relation of many files within same folder is so weak there is no need to keep them close.

In *program files* folders the access relation of the files within the same folders is weak? I don't think so. If you exclude uninstallers, readme files or unused language files (usually small compared to other files), all other files in the same folder (DLLs, additional EXEs, help files...) are supposed to be used when the application is launched/used, so there will be a benefit from placing them together.

Well, I have just chosen Executable folder from my MS Office 2003 instalation 
C:\Program Files (x86)\Microsoft Office\OFFICE11\
In 7-zip GUI - which is usable also as free 64bit file manager -I have created list of contained files, sorted according to last access timestamps. As you can see, access relation of many files is questionable.

Code:

OIS.EXE 2010-02-10 07:56
NPOFFICE.DLL 2010-02-10 07:56
MSACCESS.EXE 2010-02-10 07:56
INFOPATH.EXE 2010-02-10 07:56
IEAWSDC.DLL 2010-02-10 07:56
GRAPH.EXE 2010-02-10 07:56
WORDVIEW.EXE 2010-02-10 07:37
MSOHEV.DLL 2010-02-10 07:31
REFIEBAR.DLL 2010-02-10 07:30
MSPUB.EXE 2010-02-10 07:29
EXCEL.EXE 2010-02-10 07:29
WINWORD.EXE 2010-02-10 07:29
MSOHTMED.EXE 2010-02-10 07:29
PPTVIEW.EXE 2010-02-10 07:29
POWERPNT.EXE 2010-02-10 07:29
MULTIMGR.DLL 2010-02-10 07:29
PPTPRTID.XML 2010-02-10 07:29
MSPPT.OLB 2010-02-10 07:29
UNICOWS.DLL 2010-02-10 07:29
WWPAB.CNV 2010-02-09 23:49
REFBAR.ICO 2010-02-09 07:30
MSN.ICO 2010-02-07 23:21
GDIPLUS.DLL 2010-02-06 01:06
PROFLWIZ.EXE 2010-02-06 01:06
MCPS.DLL 2010-02-04 06:02
MSOSTYLE.DLL 2010-02-03 00:32
XLCALL32.DLL 2010-02-03 00:32
MSODCW.DLL 2010-01-02 21:13
WDVPRTID.XML 2009-12-20 08:36
BIDI32.DLL 2009-12-20 08:36
INTLDATE.DLL 2009-12-20 08:36
UCSCRIBE.DLL 2009-12-20 08:36
SAEXT.DLL 2009-12-20 08:36
WRDPRTID.XML 2009-12-20 08:36
EXLPRTID.XML 2009-12-20 08:36
STSLIST.DLL 2009-12-20 08:36
FPDTC.DLL 2009-12-20 08:36
MSOWCW.DLL 2009-12-20 08:36
MSWORD.OLB 2009-12-20 08:36
XML2WORD.XSL 2009-12-20 08:36
REFEDIT.DLL 2009-11-12 20:58
MSTORDB.EXE 2009-11-12 20:58
INLAUNCH.DLL 2009-11-12 20:58
MSCAL.OCX 2009-11-12 20:58
SOA.DLL 2009-11-12 20:58
MSTORE.EXE 2009-11-12 20:58
NAME.DLL 2009-11-12 20:58
oisctrl.dll 2009-11-12 20:58
AW.DLL 2009-11-12 20:58
MSJSPP40.DLL 2009-11-12 20:58
MSACC.OLB 2009-11-12 20:58
ACWZMAIN.MDE 2009-11-12 20:58
ACWZLIB.MDE 2009-11-12 20:58
ACWZUSR.MDT 2009-11-12 20:58
HLP95EN.DLL 2009-11-12 20:58
MSRTEDIT.DLL 2009-11-12 20:58
DSITF.DLL 2009-11-12 20:58
DSSM.EXE 2009-11-12 20:58
XL5EN32.OLB 2009-11-12 20:58
MSTORES.DLL 2009-11-12 20:58
MSOCF.DLL 2009-11-12 20:58
CDLMSO.DLL 2009-11-12 20:58
OISAPP.DLL 2009-11-12 20:58
OISGRAPH.DLL 2009-11-12 20:58
WDBIMP.DLL 2009-11-12 20:58
MSOAUTH.DLL 2009-11-12 20:58
MULTIQ.DLL 2009-11-12 20:58
SETLANG.EXE 2009-11-12 20:58
AUTHZAX.DLL 2009-11-12 20:58
RSWOP.ICM 2009-11-12 20:58
PTXT9.DLL 2009-11-12 20:58
MSPUB.TLB 2009-11-12 20:58
OWSCLT.DLL 2009-11-12 20:58
OWSSUPP.DLL 2009-11-12 20:58
MSWEBCAP.DLL 2009-11-12 20:58
MSCAL.HLP 2009-11-12 20:58
FPCUTL.DLL 2009-11-12 20:52
OMFC.DLL 2009-11-12 20:52
WORD.PIP 2009-11-12 20:52
WORDMAIL.PIP 2009-11-12 20:52
WAVTOASF.EXE 2009-11-05 13:43
REFBARH.ICO 2009-11-05 13:43
OPW11USR.INI 2009-05-02 08:24
ACCWIZ.DLL 2009-03-18 02:16
STSUPLD.DLL 2009-03-18 02:16
SEQCHK10.DLL 2009-02-08 13:51
PUBTRAP.DLL 2009-02-08 13:51
PUBENV.DLL 2009-02-08 13:51
PUBCONV.DLL 2009-02-08 13:51
PRTF9.DLL 2009-02-08 13:51
MSOCFU.DLL 2009-02-08 13:51
MSAEXP30.DLL 2009-02-08 13:51
Microsoft.Office.Interop.I... 2009-02-08 13:51
Microsoft.Office.Interop.I... 2009-02-08 13:51
IPDMCTRL.DLL 2009-02-08 13:51
INTLBAND.HTM 2008-11-11 07:58
POWERPOI.PIP 2008-06-04 07:21
INFOPATH.PIP 2008-05-17 10:47
UTILITY.MDA 2008-05-17 10:47
ACWZDAT.MDT 2008-05-17 10:12
OEMPRINT.CAT 2008-05-17 10:12
MSCOL11.PPD 2008-05-17 10:12
MSCOL11.INF 2008-05-17 10:12
PUBLISHE.PIP 2008-05-17 10:12
SMSW.CHM 2008-05-17 10:11
RESETO11.OPS 2008-05-17 10:11
OIS.PIP 2008-05-17 10:11
EXCEL.PIP 2008-05-17 10:11
MSCAL.CNT 2008-05-17 10:11
MSCAL.DEP 2008-05-17 10:11

[MiguelMS]

Most of possible approches has their own flaws.
One need always keep in mind if maintainence of their layout does not cost more, that is gain what they provide.

I agree That's what makes MyDefrag that good, we all can write a fully customized script just for our computer and the specific use of programs or files we do

I usually divide active files into 2 groups with similar size, divided by MFT/folders zone, sometimes with small files zone

(begin of disk)
Recently accessed 1
Recently created or modified 1

MFT+$files
folders
(optionally often accessed files <64-128kB )

Recently accessed 2
Recently created or modified 2

Rest of files.

Clever approach, I liked it MFT and metadata files are just in the middle of the supposedly more frecuently accessed and modified files, so they all have the MFT placed near them. If the use of the computer is mainly the same everyday, all recently accessed and modified files would be moreless the same too. Otherwise, files may be coming and going from "recently accessed and modified" and "rest of files".

Well, I have just chosen Executable folder from my MS Office 2003 instalation 
C:\Program Files (x86)\Microsoft Office\OFFICE11\
In 7-zip GUI - which is usable also as free 64bit file manager -I have created list of contained files, sorted according to last access timestamps. As you can see, access relation of many files is questionable.

Didn't think of a "multiple component" programs like MS Office. Now I see what you were referring to. Someone may use Word but not Excel, then Excel files residing in the same folder would go unused. Thanks for pointing this.

"non-multiple component" programs don't have such a weak relation on the last access timestamps. I have chossen Mozilla Firefox and Windows Defender (I used the command "DIR /TA"):

Code:

Directorio de C:\Archivos de programa\Windows Defender

16/01/2010  00:00            74.999 wgadef.chm
11/02/2010  00:00           320.280 MpClient.dll
11/02/2010  00:00            52.504 MpRtPlug.dll
16/01/2010  00:00           513.816 MpSoftEx.dll
11/02/2010  00:00           635.752 MsMpRes.dll
12/02/2010  00:00            83.224 MpShHook.dll
16/01/2010  00:00           140.056 MpSigDwn.dll
07/02/2010  00:00            57.704 MpAsDesc.dll
11/02/2010  00:00           271.128 MpSvc.dll
02/02/2010  00:00           215.320 MsMpCom.dll
12/02/2010  00:00            11.032 MsMpLics.dll
03/02/2010  00:00            29.544 mpevmsg.dll
11/02/2010  00:00           693.016 MpRtMon.dll
11/02/2010  00:00           460.080 LegitLib.dll
11/02/2010  00:00            85.272 MpOAv.dll
11/02/2010  00:00           293.144 MpCmdRun.exe
11/02/2010  00:00            13.592 MsMpEng.exe
11/02/2010  00:00           866.584 MSASCui.exe

--------------------------------------

 Directorio de C:\Archivos de programa\Mozilla Firefox

02/02/2010  00:00            17.880 AccessibleMarshal.dll
16/01/2010  00:00            31.393 LICENSE
16/01/2010  00:00                 0 .autoreg
11/02/2010  00:00             2.126 application.ini
16/01/2010  00:00               308 README.txt
16/01/2010  00:00             2.552 blocklist.xml
12/02/2010  00:00           908.248 firefox.exe
10/02/2010  00:00           120.280 crashreporter.exe
16/01/2010  00:00               478 freebl3.chk
11/02/2010  00:00           249.856 freebl3.dll
11/02/2010  00:00           918.488 js3250.dll
11/02/2010  00:00           722.392 mozcrt19.dll
16/01/2010  00:00               232 browserconfig.properties
11/02/2010  00:00           169.432 nspr4.dll
11/02/2010  00:00           636.376 nss3.dll
16/01/2010  00:00            23.996 install.log
11/02/2010  00:00           316.888 nssckbi.dll
16/01/2010  00:00               478 nssdbm3.chk
11/02/2010  00:00               476 crashreporter-override.ini
11/02/2010  00:00            98.304 nssdbm3.dll
11/02/2010  00:00            87.512 nssutil3.dll
11/02/2010  00:00               141 platform.ini
11/02/2010  00:00            20.440 plc4.dll
16/01/2010  00:00             2.867 crashreporter.ini
11/02/2010  00:00            17.368 plds4.dll
11/02/2010  00:00           103.896 smime3.dll
16/01/2010  00:00               478 softokn3.chk
11/02/2010  00:00           155.648 softokn3.dll
11/02/2010  00:00           457.688 sqlite3.dll
11/02/2010  00:00           136.664 ssl3.dll
11/02/2010  00:00                 6 update.locale
16/01/2010  00:00               112 old-homepage-default.properties
10/02/2010  00:00           244.696 updater.exe
11/02/2010  00:00            17.880 xpcom.dll
11/02/2010  00:00        10.810.840 xul.dll
16/01/2010  00:00            16.549 removed-files
17/01/2010  00:00               681 updater.ini

Anyway, his/her script zone 5 already have a "LastAccess(,1 month ago)", so it will get only the recently accessed files.


Thanks Poutnik

[poutnik]

By recently I use "1 month ago".

Even small differences in LastAccess timestamp like few days are violating hypothesis
there is strong file access relation ( like accessed when other file is accessed too )