Apparent size counting option
Closed this issue · 11 comments
Hi, fuse mounts sometimes show file size as zero. DU has an "--apparent-size" option, which allows it to count the file size nontheless. This would be useful for qdirstat also.
This is for example the output of DU:
$ du -sh /home/oernii/mnt/android/DCIM/100ANDRO/
0 /home/oernii/mnt/android/DCIM/100ANDRO/
$ du -sh --apparent-size /home/oernii/mnt/android/DCIM/100ANDRO/
188M /home/oernii/mnt/android/DCIM/100ANDRO/
Qdirstat shows this folder as 0 bytes
PS: I am using "adbfs" fuse filesystem, which does this.
This sounds like that "adbs" fuse filesystem is fundamentally broken: It does not appear to report a correct number of allocated (512 bytes) blocks for any file. That probably means that the cluster size is calculated as a wrong value (0 bytes? I'll have to check), so all allocated sizes are bogus.
What the du authors in their infinite wisdom call "apparent size" is really the size in bytes as reported by the stat() system call; which is what QDirStat shows you by default anyway for files (and other non-directory filesystem objects).
And then there is the true allocated size, which of course depends on the size of the minimum block allocation unit a.k.a. the cluster size, and the number of allocated blocks also reported by the stat() system call. It looks like that cluster size cannot be determined correctly on that filesystem type, or it consistently always reports 0 allocated blocks.
See also the QDirStat 1.7 release notes and issue #134 where this is explained in great detail.
Please check the QDirStat log file for this filesystem type: What cluster size does it report, and what file is used for that purpose?
grep -i cluster /tmp/qdirstat-$USER/*.log
2024-07-30 21:41:48.935 [8205] <Info> DirTree.cpp:685 detectClusterSize(): Cluster size: 8 blocks (4.0 kB)
2024-07-30 21:41:48.935 [8205] <Debug> DirTree.cpp:687 detectClusterSize(): Derived from /etc/magic 113 Bytes (allocated: 4.0 kB)QDirStat uses a very small but non-zero sized file for that purpose; a file with just a few bytes (like /etc/magic in this case with 113 bytes) consumes one cluster (in this case 8 blocks of 512 bytes each, i.e. 4 kB), so this is the cluster size.
On that "adbfs" filesystem type the block size of such a tiny file might be reported as 0. Please check.
There is a chance that no cluster size could be determined if there simply is no small file in that directory tree. In that case, it might remain at 0 blocks per cluster.
If you can, please rebuild with commit 366367b and check if that fixes the problem.
I just checked that last theory by forcing the bytes per cluster to 0, and the only difference is that for small files, you won't get the 113 bytes (4k) output, just 113 bytes. That probably means that this "adbfs" filesystem consistently reports 0 blocks allocated for everything.
You can check that with the stat command: It reports both sizes, the byte ("apparent") size and the number of allocated blocks:
stat /etc/magic
File: /etc/magic
Size: 113 Blocks: 8 IO Block: 4096 regular file
Device: 813h/2067d Inode: 524297 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-07-30 21:06:51.109870116 +0200
Modify: 2021-09-09 16:03:20.000000000 +0200
Change: 2022-10-01 16:52:56.760033944 +0200
Birth: 2022-10-01 16:52:56.760033944 +0200
Very likely "Blocks" will always report 0 on the "adbfs" filesystem.
Why this matters is because QDirStat uses the sum of the allocated size when displaying directory trees; see the 1.7 release announcement and #134 why.
Actually, that case that a filesystem does not want to report blocks should already be covered, too:
https://github.com/shundhammer/qdirstat/blob/master/src/FileInfo.cpp#L114-L126
and
https://github.com/shundhammer/qdirstat/blob/master/src/FileInfo.cpp#L671-L691
Waiting for feedback.
No feedback.
Why do I even bother?
There isn't even an official adbfs package for openSUSE (no matter which flavor). There are two community packages, both with a version number 0.0-git-..., i.e. some random Git snapshots. That doesn't bode well for the maturity of that project.
But it gets worse:
https://aur.archlinux.org/packages/adbfs-git
The repo for this package hasn't been updated for 8 years.
Instead, use the package adbfs-rootless-git, which is based on the maintained fork at: https://github.com/spion/adbfs-rootless
...where the last change to the code was also 5 years ago. Yet the project never made it to a released version; there are just Git snapshots around. What status does this have? Alpha? Pre-alpha? That's anybody's guess.
This looks very much like an incomplete abandoned project.
Thank you, that last commit #366367bf2af060aa1b1c6ceb052e2f6239990748 seemd to work great!
PS: sorry for the lack of lack of feedback, I was offline for a couple of weeks.