add support for compressed files about qdirstat HOT 5 CLOSED

Well, the title did NOT say it all. Actually, that never works. That's just being lazy; or unable to express your thoughts. You are leaving me guessing what it is that you actually want. What do you mean with "support"?

from qdirstat.

Hi Stefan, sorry for being too vague and thanks for the quick reply. The file size normally reported by eg. "ls -l" gives you the amount of bytes in the file. Due to internal organization of some file systems, this number is often rounded to the next multiple of the internal block size (normally 512 or 4096) byte, so the file (especially small ones) will use more of space than the actually have content.
Some filesystems (eg. btrfs) have the ability to transparently compress files with a given compression algorithm. The amount of compression (or btrfs) can be seen by using the compsize command:

$ sudo compsize /usr/lib/libQt5WebEngineCore.so.5.15.15
Processed 1 file, 849 regular extents (849 refs), 0 inline.

where "Disk Usage" gives you the actual amount of disk space used.
So the idea is to have a switch which toggles between the file size reported by "ls -l" (127M in this case) and the used disk space (by compression and padding, 94M).

There are also other filesystems features, like reflinks, sparse files, ...

See man compsize for a detailed descriptions (for btrfs only). Hope this gives you a bit more information.

from qdirstat.

You are confusing several concepts that have nothing to do with each other.

Allocated vs. Byte Size

One is the allocated size of a file vs. the nominal ("byte") size: Almost all filesystems allocate disk space in clusters (typically 4k), so a file always consumes multiples of the cluster size. That's only a minor thing for large files, but for very small ones (just a few clusters) it can really make a difference: A 46 bytes file almost always consumes one whole cluster, i.e. 4096 (4k) bytes.

But that has nothing to do with compression, and QDirStat already tells you both sizes, especially when they are very different. That was the focus of the V1.7 release of QDirStat three and a half years ago, and it was documented there and in issue #134 extensively.

Btrfs Compression

What you meant with support for compression was obviously Btrfs compression. That is a filesystem feature that is very specific to Btrfs.

And like all things Btrfs, the enfant terrible of filesystems, it behaves in weird, unpredictable ways. And the Btrfs developers, like always, insist on all related tools always requiring root permission because - well, because reasons (no better explanation given). That makes them inaccessible for normal users.

You can't even use mundane tools like btrfs df to figure out the true free disk space (as opposed to the blatantly lying result they return to normal tools like df or the statfs() syscall) without root permissions. I consider that a severe bug, but they don't care.

If anything, querying a very specialized tool like Btrfs compsize would be something to assign to a cleanup action in QDirStat; you can do that yourself. But you'll need to prefix it with sudo and have your sudo environment set up in a way where you can use it without supplying the password there and then.

QDirStat does not and will not prompt the user for a password for elevated permissions; that would destroy the user community's trust base. If you wish to run it with root permissions, that is certainly possible, and your free choice. But it will not nag you for a sudo password.

So, bottom line: The Btrfs developers misdesigned that; it's them who'd need to fix it.

from qdirstat.

More about Btrfs and their approach to reporting free disk space (and needing root permissions to do even that basic task):

https://github.com/shundhammer/qdirstat/blob/master/doc/Btrfs-Free-Size.md

Whatever made them think that either was a good idea (the false df reporting and requiring root permissions) is beyond me.

from qdirstat.

You are confusing several concepts that have nothing to do with each other.
Allocated vs. Byte Size

I'm not confused by it, it just came into my mind while I wanted to formulated something around compression. And yes, it has nothing to do with compression. I somehow miss that qdirstat already implements allocated space.

Btrfs Compression

yes, it's a bit sad that it seems that there is no clean (without root) and generic! (all filesystems with compression support) way to get the allocated size of a compressed file. Maybe in the future. Thanks!

from qdirstat.