[GH-ISSUE #234] Visiting directory with hard linked files produces unstable result #106

New Issue

2026-06-08T11:25:43+03:00

zhus commented

2026-06-08 11:25:43 +03:00

Originally created by @gwy15 on GitHub (Aug 14, 2022).
Original GitHub issue: https://github.com/bootandy/dust/issues/234

The issue

Let's say I have this directory with the following structure

$ tree
.
├── sample
│   └── sample.txt
├── sample2
│   └── sample2.txt
└── sample3
    └── sample3.txt

3 directories, 3 files

where sample.txt, sample2.txt and sample3.txt have the same inode (hard linked).

Running dust produces unstable results,

 dust -r -b
 1.0G └─┬ .
 1.0G   ├─┬ sample2
 1.0G   │ └── sample2.txt
   0B   ├── sample3
   0B   └── sample

1.0G └─┬ .
 1.0G   ├─┬ sample
 1.0G   │ └── sample.txt
   0B   ├── sample3
   0B   └── sample2

Expected behavior

From my personal perspective, I would want the result to be stable, i.e., always list the size under directory sample.
If possible, I would prefer that I can specify the order to visit directories from command line arguments.

I understand that the code visit directories in a parallel way, will this be a problem to produce a stable result?

Originally created by @gwy15 on GitHub (Aug 14, 2022). Original GitHub issue: https://github.com/bootandy/dust/issues/234 # The issue Let's say I have this directory with the following structure ``` $ tree . ├── sample │ └── sample.txt ├── sample2 │ └── sample2.txt └── sample3 └── sample3.txt 3 directories, 3 files ``` where `sample.txt`, `sample2.txt` and `sample3.txt` have the same inode (hard linked). Running `dust` produces unstable results, ``` dust -r -b 1.0G └─┬ . 1.0G ├─┬ sample2 1.0G │ └── sample2.txt 0B ├── sample3 0B └── sample ``` ``` 1.0G └─┬ . 1.0G ├─┬ sample 1.0G │ └── sample.txt 0B ├── sample3 0B └── sample2 ``` # Expected behavior From my personal perspective, I would want the result to be stable, i.e., always list the size under directory `sample`. If possible, I would prefer that I can specify the order to visit directories from command line arguments. I understand that the code visit directories in a parallel way, will this be a problem to produce a stable result?

zhus closed this issue

2026-06-08 11:25:43 +03:00

zhus commented

2026-06-08 11:25:43 +03:00

@bootandy commented on GitHub (Aug 15, 2022):

I can't guarantee stable results. Because we have several threads running, which ever 'finds' it first will include it.

I would rather have it be stable too but I'm not sure the best way to do this.
( We could revive dust --num-threads=1 and force it to run with a single thread. That way results should be stable. )

dust -s will show apparent size and will create an output similar to tree if that helps, this should be stable.

@bootandy commented on GitHub (Aug 15, 2022): I can't guarantee stable results. Because we have several threads running, which ever 'finds' it first will include it. I would rather have it be stable too but I'm not sure the best way to do this. ( We could revive `dust --num-threads=1` and force it to run with a single thread. That way results should be stable. ) `dust -s` will show apparent size and will create an output similar to tree if that helps, this should be stable.

zhus commented

2026-06-08 11:25:43 +03:00

@gwy15 commented on GitHub (Aug 18, 2022):

how about visit files concurrently and save the inodes first, then later decide which directory the inodes belong to? This should not compromise speed but should produce a stable result.

@gwy15 commented on GitHub (Aug 18, 2022): how about visit files concurrently and save the inodes first, then later decide which directory the inodes belong to? This should not compromise speed but should produce a stable result.

zhus referenced this issue

2026-06-08 11:27:00 +03:00

[PR #106] [CLOSED] Change bar graphs #308

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bootandy/archived-dust#106