Comments on: Baobab/Disk Usage Analyzer http://thomas.apestaart.org/log/?p=1027 Present Perfect Sun, 19 May 2013 16:40:23 +0000 hourly 1 http://wordpress.org/?v=abc By: Julian Hughes http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-57913 Julian Hughes Tue, 29 Sep 2009 20:42:48 +0000 http://thomas.apestaart.org/log/?p=1027#comment-57913 du is ok but ncdu is better :-) It's du in an interactive ncurses interface so you can toggle sorting by name/size, toggle being asked before delete, toggle dirs before files when sorting, show percentage and/or graph, between apparent size and disk usage, between powers of 1000 and 1024. If you make any changes you press 'r' and it recalculates. It works very efficiently just like du. You can have it stay within the filesystem and you can run it on individual directories. It's very simple, has built in help menu, and looks nice so is just as suitable for a GUI desktop as it is when used on a console system (i.e. remote machine via ssh). I have it as a Thunar custom action (file manager right click context menu) on my desktop and laptop and I even managed to build a package for my not-powerful Nokia N810 (armel). I assume it can be integrated into other GUI file manager context menus as well but I'm not really familiar with Nautilus and Konqueror etc. du is ok but ncdu is better :-) It’s du in an interactive ncurses interface so you can toggle sorting by name/size, toggle being asked before delete, toggle dirs before files when sorting, show percentage and/or graph, between apparent size and disk usage, between powers of 1000 and 1024. If you make any changes you press ‘r’ and it recalculates. It works very efficiently just like du. You can have it stay within the filesystem and you can run it on individual directories.

It’s very simple, has built in help menu, and looks nice so is just as suitable for a GUI desktop as it is when used on a console system (i.e. remote machine via ssh). I have it as a Thunar custom action (file manager right click context menu) on my desktop and laptop and I even managed to build a package for my not-powerful Nokia N810 (armel). I assume it can be integrated into other GUI file manager context menus as well but I’m not really familiar with Nautilus and Konqueror etc.

]]> By: J.B. Nicholson-Owens http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-57111 J.B. Nicholson-Owens Sat, 19 Sep 2009 21:08:20 +0000 http://thomas.apestaart.org/log/?p=1027#comment-57111 I'd prefer to do this from within Nautilus -- the "size" column should not show a mix of filesizes and directory object counts. I find the directory object counts to be useless. I'd much rather know how much data is in a directory. So I'd like Nautilus to recursively add up the sizes of everything in a directory and present that size to me for the size of that directory, just as Nautilus does if you get info on a directory. I believe the MacOS Finder has behaved this way in "list view" for quite some time. I filed an improvement bug against Nautilus to this effect. I'm learning Python and plan to investigate writing a Python extension to get Nautilus to do what I want. As for using the command-line, I can do that but my GUI-dependent colleagues cannot do that as easily. I find all of the graphs I've seen (Pysize's graph, Baobab's graph, etc.) to be unclear and undesirable. I'd much prefer an integrated approach for this, hence getting Nautilus to do what I want. I’d prefer to do this from within Nautilus — the “size” column should not show a mix of filesizes and directory object counts. I find the directory object counts to be useless. I’d much rather know how much data is in a directory. So I’d like Nautilus to recursively add up the sizes of everything in a directory and present that size to me for the size of that directory, just as Nautilus does if you get info on a directory. I believe the MacOS Finder has behaved this way in “list view” for quite some time. I filed an improvement bug against Nautilus to this effect. I’m learning Python and plan to investigate writing a Python extension to get Nautilus to do what I want.

As for using the command-line, I can do that but my GUI-dependent colleagues cannot do that as easily. I find all of the graphs I’ve seen (Pysize’s graph, Baobab’s graph, etc.) to be unclear and undesirable. I’d much prefer an integrated approach for this, hence getting Nautilus to do what I want.

]]> By: Thomas http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-57068 Thomas Sat, 19 Sep 2009 11:38:27 +0000 http://thomas.apestaart.org/log/?p=1027#comment-57068 @Matteo: I have to violently disagree. I just tried gdmap. It was already confusing to figure out how to make it scan my home directory (arguably partly to blame there is the file selector, but even still, after thinking I selected my /home/thomas directory it took it quite a while and only then did it show me it actually scanned /home instead) and I have no idea what to do with all the coloured different-sized squares I now see. How is that useful ? I see colours that I don't understand, squares I can mouse-over that seem to point at some directories. I don't easily see the first-level grouping (although I do see when I mouseover that some cyan rectangle is outlining them, but mouseover hunt and peck is hardly a good interface.) I'm terribly unimpressed at gdmap and it definitely is not going to help me figure out the bigger disk wasters in 5 minutes. @Matteo: I have to violently disagree. I just tried gdmap. It was already confusing to figure out how to make it scan my home directory (arguably partly to blame there is the file selector, but even still, after thinking I selected my /home/thomas directory it took it quite a while and only then did it show me it actually scanned /home instead) and I have no idea what to do with all the coloured different-sized squares I now see. How is that useful ? I see colours that I don’t understand, squares I can mouse-over that seem to point at some directories. I don’t easily see the first-level grouping (although I do see when I mouseover that some cyan rectangle is outlining them, but mouseover hunt and peck is hardly a good interface.)

I’m terribly unimpressed at gdmap and it definitely is not going to help me figure out the bigger disk wasters in 5 minutes.

]]> By: Fabio Marzocca http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56844 Fabio Marzocca Thu, 17 Sep 2009 10:32:19 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56844 Thank you Thomas! I'm glad to know you find it useful. Fabio Thank you Thomas! I’m glad to know you find it useful.

Fabio

]]> By: Jinks http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56744 Jinks Wed, 16 Sep 2009 11:16:27 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56744 Visually I still prefer KDE's FileLight, which afaict was there *way* before baobab. Visually I still prefer KDE’s FileLight, which afaict was there *way* before baobab.

]]> By: Justin http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56648 Justin Tue, 15 Sep 2009 14:36:27 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56648 The better way you were looking for was: du -acx ~ | sort -n The better way you were looking for was:

du -acx ~ | sort -n

]]> By: Koen Vervloesem http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56634 Koen Vervloesem Tue, 15 Sep 2009 10:36:13 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56634 Another interesting tool is agedu: it records the last-access times of every file it scans and then it generates an HTML report. The space occupied by each directory is represented by a coloured bar, drawn in lots of different colours: red for files that haven't been looked at for a long time, green for very recently accessed files, and a whole colour spectrum for the points in between. So you can immediately see that a specific subdirectory is not only the largest, but also that it consists mostly of files you haven't looked at for months. http://www.chiark.greenend.org.uk/~sgtatham/agedu/ Another interesting tool is agedu: it records the last-access times of every file it scans and then it generates an HTML report. The space occupied by each directory is represented by a coloured bar, drawn in lots of different colours: red for files that haven’t been looked at for a long time, green for very recently accessed files, and a whole colour spectrum for the points in between. So you can immediately see that a specific subdirectory is not only the largest, but also that it consists mostly of files you haven’t looked at for months.

http://www.chiark.greenend.org.uk/~sgtatham/agedu/

]]> By: Matteo http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56629 Matteo Tue, 15 Sep 2009 09:12:04 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56629 even better than baobab: gdmap even better than baobab: gdmap

]]> By: pvandewyngaerde http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56625 pvandewyngaerde Tue, 15 Sep 2009 09:03:22 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56625 Your comments did not show up in my FF versions 3.5.3 also take a look at this http://shibuvarkala.blogspot.com/2008/12/gt5-disk-usage-browser-for-ubuntu-linux.html Your comments did not show up in my FF versions 3.5.3

also take a look at this
http://shibuvarkala.blogspot.com/2008/12/gt5-disk-usage-browser-for-ubuntu-linux.html

]]> By: Justin Haygood http://thomas.apestaart.org/log/?p=1027&cpage=1#comment-56598 Justin Haygood Tue, 15 Sep 2009 03:29:22 +0000 http://thomas.apestaart.org/log/?p=1027#comment-56598 the opensuse servers at my employer run baobob alot.. wonderful application the opensuse servers at my employer run baobob alot.. wonderful application

]]>