The properties of Thunar show a filesize of 140,8 TB for the file /proc/kcore. Thunar should be able to read the correct filesize because even the "du" command in Linux does that. btw other filemanagers have the same problem. Another question is why thunar doesn't just use "du" for giving filesize but uses its own algorithm?
We can do 2 things here: Only count file/dirs on the same filesystem. So counting / will exclude /proc /dev but also /home if this is a custom partition. Like the -x option in du. Always return 0 for filesizes in /proc /dev when deep counting.
No, for the root directory we should use something like "df". Just giving the Partition sizes is muuuch faster. Actually, we could just exclude all virtual filesystems because they do not occupy any memory ("df -a" <-> df").
The same deep count job also counts the number of files and folders. Not only the size, so size does not slowdown this process. Personally I'd say only counting files on the same filesystem is easy and fast. This is also suggested for nautilus: https://bugzilla.gnome.org/show_bug.cgi?id=629394
An advantage is that if you request the size of / it wont start to traverse the remote filesystems too (mounted in /media or /run/some/where/).
> "[...] so size does not slowdown this process." I cant quite believe this. With 'df' the partition sizes are shown instantly. 'du' needs some time. If it really doesn't slow down the process, than why don't you first calculate the overall size AND THEN the number of files and folders? That would at least display the size without delay. > "An advantage is that if you request the size of / it wont start to traverse the remote filesystems too (mounted in /media or /run/some/where/)." That actually convinced me :-)
Fixed in master. There was also a bug that made the code query the file info twice in a very inefficient way, so it's probably a lot quicker too. Not directly tho, the G_FILE_ATTRIBUTE_FILESYSTEM_USED attribute was added in 2.32.