Skip to content

fix: -t with -m sums timestamps instead of taking the newest - #612

Merged
bootandy merged 2 commits into
bootandy:masterfrom
VXNCXNX:fix/filetype-filetime-summed
Aug 18, 2026
Merged

fix: -t with -m sums timestamps instead of taking the newest#612
bootandy merged 2 commits into
bootandy:masterfrom
VXNCXNX:fix/filetype-filetime-summed

Conversation

@VXNCXNX

@VXNCXNX VXNCXNX commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

-t (group by file type) combined with -m (show filetimes) adds the timestamps
together, so every group shows a date a century in the future.

Three .log files with mtimes 2020-01-01, 2021-06-15 and 2022-03-10:

$ dust -P -c -w 60 -t -m m demo
before:
2123-08-24T12:00:00   ┌──.log
2123-08-24T12:00:00 ┌─┴(total)

after:
2022-03-10T12:00:00   ┌──.log
2022-03-10T12:00:00 ┌─┴(total)

The same tree without -t already prints 2020, 2021 and 2022 correctly, which is
the reference the grouped view should agree with.

Cause

When by_filetime is set, node.size holds a timestamp rather than a size, and
get_all_file_types already knows that in two places:

let actual_size = if by_filetime.is_some() {
    ext_nodes_iter.map(|node| node.size).max().unwrap_or(0)
} else {
    ext_nodes_iter.map(|node| node.size).sum()
};

The per-extension accumulator in build_by_all_file_types was not given the same
treatment, so it keeps doing *cumulative_size += node.size and sums epochs.

The fix

Pass by_filetime down and take the max instead of the sum in that one branch,
matching what the surrounding code already does. Size mode is untouched.

Verification

test_show_files_by_type_with_filetime builds the three files above and asserts
the rendered date.

Reverting only the branch back to += fails it, and the failure output is the
symptom itself:

test test_show_files_by_type_with_filetime ... FAILED
2124-06-30T12:00:00   ┌──.log
2124-06-30T12:00:00 ┌─┴(total)

I kept a test here rather than going test-free as on #609: this one needs real
files on disk, since build_by_all_file_types only counts nodes where
node.name.is_file(), so it is not the kind of one-line config change that
reads correct on sight. The timestamps are set at midday UTC so the assertion
holds regardless of the runner's timezone.

cargo test is 31 + 8 + 32 + 4 passed, 0 failed. cargo fmt --check clean.
cargo clippy reports the same two pre-existing "empty line after doc comment"
warnings before and after, in files I did not touch.

Disclosure: written with AI assistance (Claude Code). I built binaries from master and from the patched tree and produced the before and after above by running them, and ran the mutation check myself.

VXNCXNX and others added 2 commits August 16, 2026 16:43
The windows metadata time is a FILETIME (100ns ticks since 1601), not a
unix epoch, so `-m` panics in get_pretty_file_modified_time. That is
pre-existing and unrelated to this fix.

Also spells 'filetimes' as two words so the typos check passes.
@bootandy
bootandy merged commit bb0c96e into bootandy:master Aug 18, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants