Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ncdu – NCurses Disk Usage

dev.yorhel.nl

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Ncdu – NCurses Disk Usage

#141

Post by p1necone »

milderworkacc wrote: post #116

I love ncdu and install it on all of my machines. But at the risk of sounding like a broken record - why isn’t its functionality baked into stock file managers on windows and Linux? Why can’t either of these systems do what the Mac has been able to do since the 90s, and display the recursive size of a directory in bytes in the file manager, allowing one to sort directories by recursive size? I am not exaggerating to…

I assume the restriction is file system related. It's probably not always cheap to calculate the full size of a directory, especially if it's heavily nested.

Windows will tell you the size of a dir in the right click -> properties menu, but it takes a while to calculate for large/complicated directories.

Re: Ncdu – NCurses Disk Usage

#142

Post by p1necone »

lillecarl wrote: post #60
jrm4 wrote: post #55

Broadly, is anyone aware of a generalized list of "new versions of classic tools?" There are so many now that are better than the old stuff; I almost feel like a unified round up of these, maybe even in a distro form, might be good for linux enthusiasts, newcomers, old-timers, etc.

Zellij instead of tmux (not necessarily better, but it's easier to use) Xonsh instead of bash (because you already know Python, why learn a new horrible language?) bat instead of cat (syntax highlights and other nice things) exa instead of ls (just nicer) neovim instead of vim (just better) helix instead of neovim (just tested it, seems promising though) nix instead of your normal package manager (it works on Mac, an…

I'm big fan of using micro[1] instead of nano/vim as the default command line text editor.

[1] https://micro-editor.github.io/

Re: Ncdu – NCurses Disk Usage

#145

Post by danparsonson »

Wingy wrote: post #137
tetris11 wrote: post #129

Earlier quoted context omitted.

Except that running "ls" doesn't show you the directory content size, and "ncdu" requires the user to make a tea first. The above poster is right in saying that having this built-in to the filesystem metrics would be a huge win.

duc! use a cronjob for `duc index`, then you can use `duc ui` to see the index. it doesn’t immediately update on change so it’s not quite what you’re looking for, but it might be the closest thing.

Wow thank you for that! This whole thread is great - I've been missing a utility like this for ages but never took the time to go hunting for it.

Re: Ncdu – NCurses Disk Usage

#147

Post by jaxrtech »

Just fair warning. 99% of the time, ncdu is great at intuitively finding what is taking up space. Know that unlinked, but in-use files still take up "physical" disk space.

Be weary on machines that have not been restarted I'm a while. The free space reported on the file system layer may not be the same as the amount of space taken up by files.

i.e. It's possible that delete files may still be referenced by processes still running since the space will not be reclaimed until they are killed or close the fd. This commonly happens with GB of log files you deleted but at still `open()`.

That seems to be the greatest difference between Windows and Linux from an OS & file system perspective. - Windows treats files similar to a row in adl database with locking behavior: "This file entry must be deleted from the system. Tell me if I'd be locked out by another process". - Linux treats files as reference counted resources: "I no longer need this file in this directory. The underlying data can still be referenced. You can unlink it."

Re: Ncdu – NCurses Disk Usage

#148

Post by Izkata »

kqr wrote: post #122

One thing ncdu does not improve on over du | sort is that it still needs to scan the full directory structure before even displaying any result. I would like something that starts estimating sizes immediately, and then refines those estimations as it is able to spend more time. I tried writing it myself, but I ended up not quite knowing how to go about it, because just getting the count of files in a directory takes…

If you're okay with a GUI, I think that's how baobab works. I think it only shows the intermediate updates if the disk is slow enough, as I remember it doing that in the past, but checking my SSD just now it didn't.

Re: Ncdu – NCurses Disk Usage

#149

Post by Zitrax »

p1necone wrote: post #141
milderworkacc wrote: post #116

I love ncdu and install it on all of my machines. But at the risk of sounding like a broken record - why isn’t its functionality baked into stock file managers on windows and Linux? Why can’t either of these systems do what the Mac has been able to do since the 90s, and display the recursive size of a directory in bytes in the file manager, allowing one to sort directories by recursive size? I am not exaggerating to…

I assume the restriction is file system related. It's probably not always cheap to calculate the full size of a directory, especially if it's heavily nested. Windows will tell you the size of a dir in the right click -> properties menu, but it takes a while to calculate for large/complicated directories.

WizTree (https://diskanalyzer.com/) on Windows seem to be faster than other tools I tried.
Post reply on HN