Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#168 When using the GUI, "Sort by last modification time" sorts by path

None
closed
nobody
None
2
2012-12-23
2012-11-14
Rainer Blome
No

Hi, thanks for developing Ultradefrag.

=== The issue

On Windows XP Pro 32bit SP3, using the GUI interface of UD 6.0.0-beta1,
"Preview" -> "Sort by last modification time"
(there is a checkmark in front of that menu entry)
and then "Full optimization"
apparently results in files being sorted by path.

I used Defraggler to check which files ended up where and it looks like Ultradefrag achieved an apparently perfect ordering by absolute path.
Exceptions are $LogFile and $MFT, which sit somewhere in the middle,
which is expected.

=== Workaround

Modifying the configuration file guiopts.lua by adding

os.setenv("UD_SORTING","M_TIME")

at the end apparently does the trick. A log of a dry_run=1 states that
files will be sorted by last modification time in ascending order.

=== Probably relevant observations from before I found the workaround

The last line of guiopts-internals.lua is sorting_flags=40,
but I did not touch that file.

The ultradefrag.log after starting and then stopping the GUI
states that it cannot query UD_SORTING_ORDER
because it could not be found in the environment,
and that files will be sorted by path in ascending order.

I do not have the log file from directly after the last "misguided" optimization.
Maybe for debugging it would help to keep the last 10 log files or so.

When I open a command prompt and set UD_SORTING=M_TIME
(and UD_LOG_FILE_PATH to a suitable value),
and then start udefrag -m -o c:,
the log file shows files will be sorted by last modification time in ascending order, and the sort order is close to being by
modification time (for example, the UltraDefrag directory ended up
at the back of the occupied space).

Trying the same trick with the GUI client, it still used the
"by path" order, as is evident from its log file.

=== Probably irrelevant details from before I found the workaround

This is after two runs of "Full optimization" with the same
"Sort by modification time" setting,
separated by cleaning up things like system restore points,
pagefile, hibernation file and UsmJnl, which includes several reboots
and at least two boot-time defrag runs with
its settings (script) unchanged by me.

I did not check file placement after the first pass,
so can't say which ordering the first pass produced.

For the second pass, I changed guiops.lua
via "Settings -> Graphical Interface -> Options":

fragment_size_threshold = "0 Mb"
file_size_threshold = ""

All other settings were and are on their default values,
in particular the optimizer_file_size_threshold is at 20 Mb.

UltraDefrag stated that it would need another pass, but
I don't see why that should help, as it had about 60% of free space
to work with and easily moved out and then back in
all regular files during the last pass
(and it had said that already after the first pass).

Discussion

  • Hi, thanks for pointing it out.

    Certainly we forgot to add the UD_SORTING and UD_SORTING_ORDER environment variables setup on GUI startup, so regardless of the selected menu items the default options are to be used after GUI restart.

    We'll fix that in v6 beta2, and currently, as you've mentioned, guiopts.lua file modification can be used as a workaround.


    Dmitri

     
  • Stefan Pendl
    Stefan Pendl
    2012-11-18

    • Status: unread --> open
     
  • Stefan Pendl
    Stefan Pendl
    2012-12-23

    fixed in v6.0.0 beta2

     
  • Stefan Pendl
    Stefan Pendl
    2012-12-23

    • status: open --> closed