Bug 381508 - Make Dolphin calculate folder size in same units as file size (in KB, MB, GB, TB, etc.)
Summary: Make Dolphin calculate folder size in same units as file size (in KB, MB, GB,...
Status: RESOLVED DUPLICATE of bug 158090
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: details mode (show other bugs)
Version: 16.08.3
Platform: Debian stable All
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-22 00:28 UTC by jbn
Modified: 2017-06-22 10:06 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jbn 2017-06-22 00:28:12 UTC
I noticed this on GNU/Linux but I believe this feature does not depend on the OS.

Folders are listed with the size column showing the number of items inside the folder. This is useless for determining which item in a folder uses up the most space on the volume.

Instead, the size column should show the amount of storage space that folder takes up (in KB, MB, GB, TB, etc.). As the folder's content changes, the size is recomputed keeping this information updated.

I understand that implementing this will generate a lot of disk/network access and that's okay. I'd like to have the option to see this information because I'd like to have an always-updated view of which folders occupy a lot of space. I'd like to get this information without another program (such as K4DirState) or running:

  du --summarize --human-readable * |sort -hr |less

on the command line to get a list of items in the current working directory sorted by their size (largest -> smallest).

This should be a togglable feature set to off by default, as it is in MacOS's Finder. I'd like it if one could turn this on, wait while the folder sizes are computed, and sort by size in a more meaningful way (no more using radically different units for folders than files).
Comment 1 Christoph Feck 2017-06-22 10:06:23 UTC

*** This bug has been marked as a duplicate of bug 158090 ***