After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 375061 - cannot open special file whose stat size is 0
cannot open special file whose stat size is 0
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
2.16.x
Other Linux
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 550852 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-11-14 11:07 UTC by Benoît Dejean
Modified: 2009-08-22 10:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Benoît Dejean 2006-11-14 11:07:40 UTC
Hi,
 on special files like '/proc/cmdline', stat size is 0 but the file is not empty. Nautilus is able to make the thumbnail for that file. If i open the file with gedit, gedit buffer remains empty. I know it's weird, but not all fs operations are implemented for procfs (and for other pseudo filesystems). So if it seems that a file size is 0 because this is was stat reports, gedit should still try to read it. Thanks.
Comment 1 Mart Raudsepp 2007-01-09 08:18:44 UTC
I can reproduce this with gedit-2.16.2, so confirming the bug and changing version field to 2.16.x, although it's most probably a problem in SVN HEAD too.

The problem was reported in Gentoo Linux too: http://bugs.gentoo.org/show_bug.cgi?id=141642
Comment 2 Paolo Borelli 2007-01-09 09:37:32 UTC
We'll prolly switch away from mmapping files and go back to reading them because of stability issues... so this should get automatically fixed
Comment 3 Paolo Borelli 2009-01-10 16:50:22 UTC
*** Bug 550852 has been marked as a duplicate of this bug. ***
Comment 4 Paolo Borelli 2009-08-22 10:31:11 UTC
I forgot to close this... in 2.27 we always use gio and proc files are now read fine. It's a bit ugly that gedit actually keeps worning you that the proc file changed since mtime changes all the time, but on the other hand ignoring the mtime changes for all files in proc doesn't sound right either.