GNOME Bugzilla – Bug 629394
Nautilus displays wrong size of "/"
Last modified: 2013-12-08 20:35:56 UTC
In nautilus, when you go to root and ask for the total size, it grows slowly and then suddenly goes to 128TB. It seems that the file causing nautilus to go to 128 TB is proc/kcore, or proc/media. I'm not sure this isn't Ubuntu-specific, but one comment said to report upstream. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/585472
Confirmed on Gentoo with Gnome 2.30.2. To reproduce: 1) Open Places->Computer. 2) Right-click File System and click Properties. Expected: Number after "totalling" should be cumulative size of files on file system. Actual: Number after "totalling" is 128.2 TB.
I am getting the same thing and i am in 10.10 64 bit ubuntu. I do not know what is causing mine or how to fix it nor do i know if it is important or not about this bug doing this. can someone give me any ideas on how to fix this? i am new to linux and i never found how to fix it or what really is the cause of this bug other then /proc/kcore or /proc/media or nautilus i have no idea how to go about fixing this anyone have any ideas?
*** Bug 633090 has been marked as a duplicate of this bug. ***
Created attachment 176172 [details] [review] patch this issue stems from stat reading out the size incorrectly. $ stat /proc/kcore File: `/proc/kcore' Size: 140737486266368 Blocks: 0 IO Block: 1024 regular file Device: 3h/3d Inode: 4026532018 Links: 1 Access: (0400/-r--------) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:proc_kcore_t:s0 Access: 2010-12-10 12:51:09.156401113 +0530 Modify: 2010-12-10 12:51:09.156401113 +0530 Change: 2010-12-10 12:51:09.156401113 +0530 Birth: - we could check st_block size, and if zero mark the file as zero size.
Created attachment 176175 [details] [review] patch update - this only applies to regular files, and not every other file.
(In reply to comment #5) > Created an attachment (id=176175) [details] [review] > patch > > update - this only applies to regular files, and not every other file. caveat : sparse file with any used block will appear larger than they are on disk
Counting the file size in /proc or /sys at all is entirely nonsense. These directories should be skipped when computing the size. Can someone set this to confirmed please?
(In reply to comment #7) > Counting the file size in /proc or /sys at all is entirely nonsense. These > directories should be skipped when computing the size. > > Can someone set this to confirmed please? Personally, I agree. wrt spare files, I believe one should display on-disk usage.
Created attachment 218249 [details] [review] deep-count-one-filesystem.patch The problem is in nautilus, not gio. I have patched nautilus so that it will not recurse into other filesystems when computing the total size of a directory.
Review of attachment 218249 [details] [review]: Thanks for the patch! I left some comments below. ::: libnautilus-private/nautilus-directory-async.c @@ +2687,3 @@ /* Record the fact that we have to descend into this directory. */ + id = g_file_info_get_attribute_string (info, G_FILE_ATTRIBUTE_ID_FILESYSTEM); + if (id && state->fs_id && strcmp (id, state->fs_id) == 0) { You can use g_strcmp0() that does the NULL checks automatically. @@ +2951,3 @@ + G_FILE_ATTRIBUTE_ID_FILESYSTEM, + G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, + NULL, NULL); This synchronous call here is wrong...you should call g_file_query_info_async() and then deep_count_load() from the callback.
Mass component change due to BZ cleanup, sorry for the noise.
Phillip, any chance you can update the patch?
Sorry, I've been pretty busy lately with a newborn, but I will try to get around to it.
Created attachment 229269 [details] [review] deep-count-one-filesystem.patch How's this look?
Review of attachment 229269 [details] [review]: Thanks Phillip, this looks almost ready to push, just a couple of minor comments: ::: libnautilus-private/nautilus-directory-async.c @@ +2705,3 @@ /* Record the fact that we have to descend into this directory. */ + id = g_file_info_get_attribute_string (info, G_FILE_ATTRIBUTE_ID_FILESYSTEM); + if (id && g_strcmp0 (id, state->fs_id) == 0) { g_strcmp0() will already do the id != NULL check for you, no need for an additional one here. @@ +2931,3 @@ + if (info) { + id = g_file_info_get_attribute_string (info, G_FILE_ATTRIBUTE_ID_FILESYSTEM); + GFile *file = (GFile *)source_object; Coding style: Nautilus always wraps if blocks in brackets, even if it's only one line. In this case though, there's no need for this check, as g_strdup will just return NULL when passed NULL as input. @@ +2993,3 @@ + NULL, + deep_count_got_info, + state); You can immediately unref the GFile here, as g_file_query_info_async() will keep the ref alive until the async callback returns.
Created attachment 229439 [details] [review] deep-count-one-filesystem.patch How about this one?
Review of attachment 229439 [details] [review]: Thanks, this looks good to me! Do you have a GNOME git account or should I push it on your behalf?
You know, I do think I have one so I could work on gparted, but I think I would feel more comfortable if you pushed it.
Okay, I now pushed this to master.
*** Bug 706283 has been marked as a duplicate of this bug. ***