25G

Here is another example, in this case defraggler debuglist does not show the *secrete invisible one cluster NTFS system file" and shows another one of these "WEIRD RED ONES" . [2013-09-19] [15:47:34.261] 00a04 3 FileCollection::Dump#357 "\__CSPANARCH10\10_10\wj100810.flv.flv", lcn: 21998373, vcn: 0, length: 107216 [2013-09-19] [15:47:34.261] 00a04 3 FileCollection::Dump#357 "\__CSPANARCH10\10_10\wj100810.flv.flv", lcn: 22105590, vcn: 107216, length: 4789

Defraggler need to decide on fragmented or not in cases like this [2013-09-19] [15:47:34.218] 00a04 3 FileCollection::Dump#357 "\__CSPANARCH10\11_10\e111910_photo.flv.flv", lcn: 365201, vcn: 0, length: 1079 [2013-09-19] [15:47:34.218] 00a04 3 FileCollection::Dump#357 "\$Extend\$RmMetadata\$TxfLog", lcn: 366280, vcn: 0, length: 1 [2013-09-19] [15:47:34.218] 00a04 3 FileCollection::Dump#357 "\__CSPANARCH10\11_10\e111910_photo.flv.flv", lcn: 366281, vcn: 1079, length: 7191 That is, a file whci starts before a ONE CLUSTER system file and continues immediatly after. This is maybe the most important of WEIRD STUFF with defraggler. - cant move the one cluster NTFS SYSTEM file - the file to be defragmented IS DEFRAGMENTED , taking into account that system fil - defraggler GUI still PAINTS the square RED as fragmented. - but does not show the reason, that locked NTFS system file "in the middle" GET THE DEVELOPERS GOING!! shld be easy fix Dont forget those blue squares which contain "no files". Same problem, both defrag threads amd GUI have to at least agree and GUI+guys need to give user information on these "NTFS-WEIRDer things"

Btw, most of the "Blue remaining lonely squares containing no files" are $ATTRIBUTES:LIST for files. Defraggler really need to handle all the NTFS system and special files in a consistent way, show them as SYSTEM or LOCKED or something similar. Whats worse, these "weird dots, red and blue" also tend to make defragmenting split an otherwise defragged file and then show it as a red square. Even worse, when running (next run) into one of these cases defraggler usually goes into this "pushing small holes thrgh alrdy huge defragged space". That is, if GUI of Defraggler wld be able to handle and present info on these cases correctly, the user wld not get totally frustrated.

Btw, the "benchmark files" is a good function, but I hope there will also be reporting on locked files, NTFS problems and the WORST, bad unreadable sectors. (not to be confused with clusters marked bad by windows, which is the often unnecessary result) The sectors are additionally often still readable if one "dives directly at them", skipping high level WIndows functions with timeouts,bad nonsense or nonexisting error-handling,etc WLd make defraggler into a more usable product than competitors, especially these days when large modern HDs tend to have sector-problms that still can be fixed (and replaced by spares by HD controller)

debug-debug3/ cant see some of the problems in just debug developer// I am a developer, failsafe embedded system some of the problems 1. defraggler cant handle the $system files, tries to optimize them although it cant (maybe except first blocks, fixed) 2. additionally it cant handle "the last" and "the first" files around $MFT, USjrnl etc. Leaves one fragment in front and one after. 3. Defraggler has problems handling the "data runs", file partly in MFT file, partly as "normal oldtime clusters" Another major reason for "persistent red spots". In the debug output these appear as two different files. Nothing wrong with that if they are handled correctly example [2013-09-03] [03:21:54.729] 01948 3 FileCollection::Dump#357 "\___arenprob\Amerikan frendi (12)-2013-09-01T22_45_00.flv", lcn: 263575104, vcn: 0, length: 1 [2013-09-03] [03:21:54.729] 01948 3 FileCollection::Dump#357 "\___arenprob\Amerikan frendi (12)-2013-09-01T22_45_00.flv", lcn: 263651892, vcn: 1, length: 35123 Lots of them, depending on how files were created, small first and then growing larger. For those who are unfamiliar, this always difficult NTFS thingy http://www.reddragon.../data_runs.html 4. the "display goes haywire" is probably only for the blue area and occures systematically when doing "move to end of disk". One cld describe as "all blue and white area is filled with repeating stripes of shades of blue" while the red areas, squares stay (mostly?) the same. I first thought it was "a smart way to show possible places to move the file", a forgotten debug, developer feature? 5. WHy not use MFT BitMap to find last empty cluster, not ask windows, or whatever ridiculous slow, for every cluster starting from the end. THat is one reason NTFS provides the (very small) BitMap system file. 6. Why doesnt "defrag freespace (allwng fragments)" directly start emptying, freeing the clusters at the very end (depending on defrag options), instead it starts "pushing holes" all thrgh the 4 billion clusters to sometimes get them to the end. SOmething smart shld also be done for "free space defrag" when options say place large files at the end. Ask the user, although defrag seem to already try to figure out borders when "small at start, large at end" 7. And finally that "days pushing holes through huge blue cluster areas defragged during latest run". SHld be possible to detect easily and, for example, instead of searching for one perfect match for the hole, try if two, three smaller files (fragmented or from end) can fill it. 8. Wld help if defraggler actually marked all locked system files, also other locked or "failed' move, defrag attempts. Give the user a possibility to output to a text file, etc. Wld help for almost all Defragler problems I have seen and debugged, sorted out. For example, the "data run red spots" files are "fixed" if copied to another partition and back again. Btw, my first "move red spot neighbors too" observation was partly the "data runs", partly "neighbors to locked and system files" 9. the "blue empty spots" miht have to do with problems handling "data runs", have not dblchecked it but seen many cases where a square is painted blue but still containes undefragged files, usually a "data run" prblem close by, or failed defrag attempt. Btw, note that WIndows API although returning with "OK" hasnt always "done the job", just means "no serious error occured". (Typical defragment problem with the APIs) AND!! CLosing he debug file during PAUSE, giving user a chance to handle the file, wld be good for the developers too, Just as a "dry run" mode, defragging without actually changing the hard disk. EXTREMELY USEFUL!! (and tests problems when the actual result turns out different) Lots of work for the developers

Nergal, using debug3. not sure, but after a quick try it seemed just debug didnt give enough details, but shld dblcheck that. BUT!!, the log file quickly grows larger than a GIGAByte, making it almost impossible to open and view without special tricks. Would be smart if defraggler wld, for example, open another log file after the analyse,etc basic stuff. THis second run-time-log file cld then be closed when pausing giving the user the possibility to open, check and delete or copy that file to have defraggler start a new "fresh" log-file, keeping it small enough to handle without special tools. Limiting size and then starting a new numbered file wld do the same. Old trick is also to not print the same line thousand times, the log shld compare the new line to the old one and just count them, finally outputting just how many times that function happened. Redirecting to a (live) console, DOS window wld also help

Nergal, found a clue to some "weird behaviour" having to do with "move to end of disk" on a partition already sppr 15% defragmented moving large files to end of disk with limit 10MB. Using /debug the debug file just kept growing and growing, to GB (GIGA) size, Turned out it was filling up with "CDefragFileList::FindFileAt" calls, writing this log text. [2013-08-17] [22:07:01.396] 01380 3 CVolumeHandleManager::GetHandle#34 Volume \: open, handle 0x00000554. [2013-08-17] [22:07:01.396] 00f14 1 CDefragmentation::MoveFilesToTail#440 Entering CDefragmentation::MoveFilesToTail [2013-08-17] [22:07:01.396] 00f14 3 CVolumeHandleManager::GetHandle#34 Volume \: open, handle 0x00000554. [2013-08-17] [22:07:01.396] 00f14 1 CDefragFileList::FindFileAt#232 FindFileAt starts for 488376243 [2013-08-17] [22:07:01.396] 00f14 1 CDefragFileList::FindFileAt#232 FindFileAt starts for 488376242 [2013-08-17] [22:07:01.396] 00f14 1 CDefragFileList::FindFileAt#232 FindFileAt starts for 488376241 etc. After half an hour I gave up, cldnt open, view the log file much before that. Note, although it was possible to exit and close the defraggler window this process, thread? continued. This "process still continues" is something I have noticed before by checking, monitoring. However, this time I guessed it was fairly OK to kill the process using Process Explorer which did it. (I run chkdsk afterwards, not sure, maybe complained abt bitmap and fixed it) Anyway, same "stuck doing something" also happened without the /debug, wasnt the major reason for seemingly "doing nothing" That is, defraggler was starting from end of disk searching for a free space in a very very slow fashion. So slow any normal user wld assume "stuck", reboot or whatever. FInal check, made a "hole" in the alrdy defragged area close to the end and now the same "move to end" did it fairly fast (tens of seconds) PS Of course, with that hole near the end a following normal frag started "moving same files again and again", like shuffling chairs in a row by moving every chair one position until one gets to the end.(instd of finding a suitable chair at the end and move it to the hole)

Btw, first irritating feature of defraggler, after the first joy of seeing what goes on both as text and dots on screen, was how seemingly out of synch, or at least delayed, these two were, and worse when additionally observing actual HD activity. (reminded of yhis when seeing all the 2-4 or more seconds of "doing map" in the log file)

Cldnt resist checking some more after having seen the basic functions in the log file. One solution to the "same files again and again" mighy be to search for "the file to stick into an empty place" from BEHIND, the ens of the partition! Now it seems defraggler searches for first suitable after the "hole" and will thus fragnebt alrdy defragged area. That is, soon run into that hole, then produce another hole slightly "below", etc,etc.. It becomes a process of "moving holes", not files, all through alrdy defragmented area.

THanks, Nergal, hadn't noticed the debug and log capabilities. Quick check, need to dblcheck when time 1. no log for the "blue occupied blocks" and defrag saying "no files" 2. one problem-file or "repeat red-dot offender" seem to be associated with failing in search for free block when trying to move and-or defragment it, but need to repeat and check what really goes on PS Found where the time is wasted, all seconds doing "the map". Also good info on how defrag searches for files to fill a "potential free block". Should help me "nail the move same files again and again every new defragging" PPS Note, the "irritating" behaviour is when lets say 50% is alrdy defragged but the rest a mess. Defraggler starts working on the already defragged "same files again and again", often from "persistent red dots" and never(maybe in a cpl of days) gets *down" to the mess. Shld be some way to define a starting point. A user-friendly, immediate report on unmovable files, $MFT etc as well as the real problem, unreadable sectors, as well as locked ones wld help a lot too

Defraggler definitely has at least two problems and two bugs. Prbl 1: the "moves same alrdy defragged files". Does not detect a large alrdy fully defragged "string" of files but starts "moving them just a little" (for another ten or more hours, again and again). Typically when a large "area" fully alrdy defragged, from start of disk, but a "the bug" in the middle. Prbl 2: GOes into "blip" mode,"blip" from watching HD LED , or using resource monitoring for HD access, CPU usage, Memory free. That is, spends some 5-20s "doing nothing" (no HD access, little CPU usage) inbetween "actual work". Typ when defragging, or moving the "list of fragm files" or a specific "block" BUG1: leaves blue blocks in empty space, but clicking them says "no files". However, it seems there actually is files there? Defraggler internal data corrupted, systematically, a;ways same way. Then BUG2, which together with above problems makes a REAL problem. Defraggler somehow messes up the access to some files (handful on 4-5 tested 2TB HDs). This leaves undefragged "red dots" in the middle of otherwise fully defragged areas. Interestingly the bug is not the one (normal) file that is left undefragged, but often it's neighbors. Note, these neighbors are also "normal movable files", and no bad sectors, have run HDDREG repeatedly. (been there, done that, "locked bad sectors" HDDREGH fixes, spare sectors, etc as well as othrws locked files) HOWEVER, when telling defraggler to move these NEIGHBOR files the graphic screen of blocks typically goes "haywire". Typically "broad stripes" of "wrong info" all over the graph-block display. Yypical overflow or over-run of data, messed up linked lists, etc? Note, this only happens during the defrag or move process, after that "normal display" returns, with the other problems as before. NET RESULT. If one of this "bad red dots" appear fairly early on the HD defragging it will also go into "move same files again and again" during repeated defrag-attempts. Never gets past that spot, except by moving the undefragged and its neighbors to another HD and a new defrag attempt. VERY IRRITATING, as defraggler "never" gets to the rest or last files on the HD. THat is, without moving all alrdy defragged files "just a little" for another 40 hours. Whats worse, sometimes in "blip" mode. One little 4kB cluster every 10th second.