unexpected priority of data display when it changed location between snapshots

[AleXoundOS]

I have the following Btrfs snapshots:

═══ /<SINGLE>/<DATA>/data/.snapshots ═════════════════════════
p ~125.5 GiB [####################] /2024-05-30T22:18:08+04:00
p ~119.9 GiB [################### ] /2025-11-03T02:58:02+04:00
p ~14.89 GiB [##                  ] /2025-12-02T11:42:05+04:00
p ~1.447 GiB [                    ] /2026-01-07T22:34:33+04:00

2024-05-30T22:18:08+04:00 snapshot is chronologically the first where telegram-chat-export-discs folder has appeared. And it appeared in 2024-05-30T22:18:08+04:00/downloads/telegram-chat-export-discs.

In 2026-01-07T22:34:33+04:00 it was moved from /downloads/telegram-chat-export-discs to /saa/telegram-chat-export-discs.

For unknown reason btdu displays telegram-chat-export-discs in the youngest 2026-01-07T22:34:33+04:00 (and it doesn't show it in older snapshots as data must be shown only in one location, which is expected):

═══ /<SINGLE>/<DATA>/data/.snapshots/2026-01-07T22:34:33+04:00/saa
p ~403.3 MiB [##################??] /telegram-chat-export-discs

But I expected to see telegram-chat-export-discs in 2024-05-30T22:18:08+04:00 as chronologically the first snapshot where telegram-chat-export-discs data appeared.

If it's not a bug, I would like an option to set chronological priority of locations, where data is shown, so that the oldest snapshot shows everything it has, without "leaking" its data to newer snapshots. The second snapshot should display only new data compared to the first (oldest) snapshot. And so on. Regardless of data locations changes between snapshots. Is it possible?

---

$ btdu --version
btdu v0.7.2

[CyberShadow]

Yes, it is not a bug; saa/telegram-chat-export-discs is preferred over downloads/telegram-chat-export-discs because it is shorter.

Is it possible?

Let me check.

[CyberShadow]

I need to think more about this.

If we want to allocate representative samples in chronological order, that implies we should also prefer allocating towards snapshots instead of the live subvolume that the snapshot was taken from. However, that conflicts with a common use case of btdu - check usage on your live subvolume, ignoring snapshots.

Furthermore, snapshots are just one special case. You could use cp --reflink to create your own pseudo-snapshots; to be consistent with that, we would need to check not just subvolume properties, but also file properties.

All this also makes the representative path selection algorithm quite complicated and possibly unintuitive.

[AleXoundOS]

Looks like there can be some math involved to find an optimal implementation of a different selection algorithm...

I think the use case of inspecting snapshots in chronological order is an important one. I do understand that cp --reflink is also responsible for reflinked copies besides btrfs subvolume snapshot. But the snapshots case is more clear to explain. And it's easy to understand why is it needed: interactively inspect what has been added in a new snapshot. The current algorithm introduces false-positives (in the case of renames) if trying to achieve the described goal using it.

[CyberShadow]

I'm thinking that maybe btdu just needs two representative path selection algorithms: chronological (as described in this issue) and reverse-chronological (new default, directly opposite of chronological). Can be toggled at runtime same as prefer/ignore live editing. Should be simple to think about but need to test overhead of stat calls etc.

[CyberShadow]

Please try the chronological branch:

https://github.com/CyberShadow/btdu/compare/chronological

[AleXoundOS]

Unfortunately, my old case with telegram-chat-export-discs is lost (snapshot 2026-01-07T22:34:33+04:00 is removed). I tried to reproduce the case with another folder my:

• in 2024-05-30T22:18:08+04:00 my was created in /downloads/Telegram
• in 2026-01-18T18:18:08+04:00 my was moved to /data/archive

In the following tests btdu is run using sudo btdu --prefer=/data/.snapshots /.

btdu 9f127d6 behavior:

═══ /<SINGLE>/<DATA>/data/.snapshots ═════════════════════════
p ~125.4 GiB [####################] /2024-05-30T22:18:08+04:00
p ~81.23 GiB [#############       ] /2025-11-03T02:58:02+04:00
p ~14.88 GiB [##                  ] /2025-12-02T11:42:05+04:00
p ~1.447 GiB [                    ] /2026-01-08T05:27:48+04:00
p ~38.67 GiB [######              ] /2026-01-18T18:18:08+04:00

═══ /<SINGLE>/<DATA>/data/.snapshots/2026-01-18T18:18:08+04:00/archive
p ~38.38 GiB [####################] /my

btdu d6a2a80 behavior:

═══ /<SINGLE>/<DATA>/data/.snapshots ═════════════════════════
p ~6.224 GiB [                    ] /2024-05-30T22:18:08+04:00
p ~2.706 MiB [                    ] /2025-11-03T02:58:02+04:00
p ~147.1 MiB [                    ] /2025-12-02T11:42:05+04:00
p ~3.009 MiB [                    ] /2026-01-08T05:27:48+04:00
p ~255.4 GiB [####################] /2026-01-18T18:18:08+04:00

═══ /<SINGLE>/<DATA>/data/.snapshots/2026-01-18T18:18:08+04:00/archive
p ~38.42 GiB [####################] /my

So, this is not the expected behavior. Not only my folder is represented in the newest snapshot, but most of other data as well.
The result is shown when chronological allocation toggle is off (Shift - C toggle was not pressed). I wonder which path selection algorithm is in effect here...

[AleXoundOS]

btdu d6a2a80 behavior: with chronological allocation on:

═══ /<SINGLE>/<DATA>/data/.snapshots ═════════════════════════
p ~126.9 GiB [####################] /2024-05-30T22:18:08+04:00
p ~119.9 GiB [################### ] /2025-11-03T02:58:02+04:00
p ~13.51 GiB [##                  ] /2025-12-02T11:42:05+04:00
p ~1.026 GiB [                    ] /2026-01-08T05:27:48+04:00
p ~371.8 MiB [                    ] /2026-01-18T18:18:08+04:00

═══ /<SINGLE>/<DATA>/data/.snapshots/2026-01-18T18:18:08+04:00/archive
p ~  0.0   B [--------------------] /my

Here my folder is shown as empty (as if I used Expert mode but I did not). And this is expected (because my was moved from /downloads/Telegram), despite being present in 2026-01-18T18:18:08+04:00:

$ du -hs /data/.snapshots/2026-01-18T18:18:08+04:00/archive/my
39G	/data/.snapshots/2026-01-18T18:18:08+04:00/archive/my

The remaining ~371 MiB in 2026-01-18T18:18:08+04:00 seem to be represented correctly, matching newly added data in 2026-01-18T18:18:08+04:00 compared to 2026-01-08T05:27:48+04:00.

final thoughts

So, based on those observations, I would say that chronological allocation does work! @CyberShadow, thank you!

The only issue which is quite unexpected is showing p ~ 0.0 B [ ] for each existing but not represented file & folder in the newest snapshot (2026-01-18T18:18:08+04:00 in my case). This reminds my --expert mode: the difference is that with --expert non-represented files & folders are shown in all snapshots.

[AleXoundOS]

It would be helpful to have a CLI option to enable "chronological allocation".

[CyberShadow]

I wonder which path selection algorithm is in effect here...

On the chronological branch, it's either chronological or reverse-chronological (the default).

It would be helpful to have a CLI option to enable "chronological allocation".

There's --chronological (97b8490).

[AleXoundOS]

On the chronological branch, it's either chronological or reverse-chronological (the default).

Nice! Both chronological and reverse-chronological are very useful! From now I will always use one or another.

There's --chronological (97b8490).

But I'm curious about the original representative order. If the lexicographical order remains the default, how the (reverse-)chronological order will be enabled via CLI?

[CyberShadow]

The idea is to completely replace the old lexicographical order, leaving only chronological and reverse-chronological.

[CyberShadow]

@AleXoundOS FYI, I pushed more commits to chronological, moving the stat calls to a new subprocess. This was needed to ensure that a slow stat call doesn't cause the UI to freeze. Would appreciate if you could give it some testing.

[AleXoundOS]

I use a3c7985 commit (from chronological branch) and quite often the program crashes:

$ sudo btdu /
Fatal error: index [27594] is out of bounds for array of length 27594

The usage pattern which can cause a crash can be as simple as:

1. sudo btdu /
2. navigate into /<SINGLE>

And then it can crash at any time.

The error message is always the same (at least on the same machine).

What prevents crashing:

• do not enter /<SINGLE>
• pause (using p key)

[CyberShadow]

@AleXoundOS Interesting, do you think you could try a debug build and get a stack trace?

[AleXoundOS]

I think that the crash was caused by a file, which was deleted, but its inode was still in use. So, that after a reboot, I couldn't reproduce the crash.

---

But recently I got another crash. And I think it is provoked by removing any files from the filesystem (using external tools e.g. rm, not using btdu) during the btdu sampling operation:

core.exception.ArrayIndexError@source/btdu/alloc.d(235): index [27594] is out of bounds for array of length 27594
----------------
??:? [0x560707c7dfc6]
??:? [0x560707c7dc32]
??:? [0x560707ca4dae]
??:? [0x560707c86ccf]
??:? [0x560707c7c83d]
??:? [0x560707c7cc1d]
source/btdu/alloc.d:235 [0x560707963b92]
source/btdu/stat/subproc.d:160 [0x5607079639a9]
source/btdu/sample/subproc.d:440 [0x56070796976d]
source/btdu/sample/subproc.d:365 [0x560707968585]
source/btdu/proto.d:138 [0x5607079676f2]
source/btdu/proto.d:87 [0x56070796716c]
source/btdu/sample/subproc.d:119 [0x5607079687f6]
source/btdu/main.d:333 [0x5607079aef53]
../.dub/packages/ae/0.0.3701/ae/utils/funopt.d:366 [0x5607079b6fcf]
../.dub/packages/ae/0.0.3701/ae/utils/main.d:54 [0x5607079b597c]
../.dub/packages/ae/0.0.3701/ae/utils/main.d:62 [0x5607079b7030]
../.dub/packages/ae/0.0.3701/ae/utils/main.d:85 [0x5607079b5952]
??:? [0x560707c869ac]
??:? [0x560707c868a6]
??:? [0x560707c866fc]
/nix/store/cgyrrrb8lp45gapyi87s71cad5mky9a2-ldc-1.41.0-include/include/d/core/internal/entrypoint.d:42 [0x5607079d0a71]
??:? [0x7f02ec42a4d7]
??:? __libc_start_main [0x7f02ec42a59a]
??:? [0x56070791bf54]