! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
thunar properties show wrong filesize of /proc/kcore (140,8 TB)
Status:
RESOLVED: FIXED

Comments

Description nucrap 2012-10-08 23:25:22 CEST
 
Comment 1 nucrap 2012-10-08 23:39:10 CEST
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?
Comment 2 Nick Schermer editbugs 2012-10-11 23:18:52 CEST
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.
Comment 3 nucrap 2012-10-11 23:50:28 CEST
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").
Comment 4 Nick Schermer editbugs 2012-10-12 08:45:07 CEST
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
Comment 5 Nick Schermer editbugs 2012-10-12 08:47:11 CEST
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/).
Comment 6 nucrap 2012-10-12 21:29:38 CEST
> "[...] 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 :-)
Comment 7 Nick Schermer editbugs 2012-10-13 17:51:46 CEST
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.

Bug #9361

Reported by:
nucrap
Reported on: 2012-10-08
Last modified on: 2012-10-13

People

Assignee:
Jannis Pohlmann
CC List:
2 users

Version

Attachments

Additional information