Ignore 'special files' (originally: Ignore the /proc filesystem)

[passcod]

Just ran: dua /. After a while, it printed:

141.02 TB /    <3 IO Error(s)>

...my local disk is not that large. By, uh, several orders of magnitude.

Going to / and running dua:

   0.00  B lost+found
   0.00  B mnt
   0.00  B root
   0.00  B srv
   2.54 KB dev
   3.52 KB .scripts
  85.26 KB run
   1.54 MB tmp
  30.85 MB etc
  81.55 MB boot
 657.30 MB sys
   1.85 GB bin
   1.85 GB sbin
  10.86 GB lib
  10.86 GB lib64
  18.13 GB opt
  19.76 GB usr
 118.48 GB home <1 IO Error(s)>
 130.30 GB var
 140.74 TB proc <2 IO Error(s)>
 141.05 TB total        <3 IO Error(s)>

Seems like /proc is reporting very weird sizes.

By the way, the different between dua / and cd /; dua was surprising, even though correct as per the help message.

[passcod]

This is dua 1.2.2.

[ghost]

@passcod Thanks a lot for letting me know! Right now, it is only being tested on OSX.

Regarding the difference in behaviour between dua and dua / - it's actually a feature. One might be inclined to do dua ~/* and expect to see everything, even though this will skip hidden directories. The dua usecase is tailored to you being somewhere on the disk and wondering: 'How much space is used here, just show it all...'. That way its just more convenient, too.

Could you do cd / && dua i and drill in to find our which part of /proc is misreported? I think I could determine if a file is actually a device and skip it.

Thanks a bunch!

[passcod]

The culprit is /proc/kcore, which is a virtual file that "contains" all possible memory. Linux supports up to 128TB of memory, so that's where that comes from. I'm not sure that ever counting procfs mounts is useful unless queried specifically, though: they'll always be zero-sized on disk, even if the files within do have a size.

[ghost]

Thank you! By the looks of it, the output is actually correct. I would be inclined to not call this one a bug, but only if du does the same. If du is smarter and ignores these special files, I think dua should do the same.

Could you let me know what du -sch /proc (or similar) produces?

[passcod]

# du -sch /proc
du: cannot read directory '/proc/1466/task/1466/net': Invalid argument
du: cannot read directory '/proc/1466/net': Invalid argument
du: cannot access '/proc/19393/task/19393/fd/4': No such file or directory
du: cannot access '/proc/19393/task/19393/fdinfo/4': No such file or directory
du: cannot access '/proc/19393/fd/3': No such file or directory
du: cannot access '/proc/19393/fdinfo/3': No such file or directory
0       /proc
0       total

[ghost]

Thank you, I believe dua should handle such files differently, and it should be possible to ignore them by checking the file flags in the file meta-data.

[Byron]

In dua v2.6.0, there is the -x flag to stay on the current file system and not cross mount points. This might already help with this issue.

Otherwise it's the question if something in the unix specific metadata can be used to differentiate them.

In case you get to test it and find that -x is not an option, please let me know or reopen the issue.

[passcod]

I'd forgotten all about this, and 2.5.0 (what arch installs currently) already reports zero for /proc, so all's fine.