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 269895 - e_fsutils_avail misreports free space, breaking migration from 1.4 to 2.0
e_fsutils_avail misreports free space, breaking migration from 1.4 to 2.0
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: general
2.0.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: Harish Krishnaswamy
Evolution QA team
evolution[migration]
Depends on:
Blocks:
 
 
Reported: 2004-11-24 23:34 UTC by Dave Malcolm
Modified: 2013-09-10 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to calculate diskspace from blocksize, rather than fragment size (563 bytes, patch)
2004-11-24 23:34 UTC, Dave Malcolm
none Details | Review
stat vs statvfs tester (461 bytes, text/plain)
2004-12-07 04:30 UTC, Not Zed
  Details

Description Dave Malcolm 2004-11-24 23:34:04 UTC
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140744

Above is a report in my downstream bugzilla of free space being
misreported; Evolution thinks it has only 1/16th of available space on an
NFS mounted home directory (from Solaris 9 server to Fedora Core 3 client)
and hence refuses to do a migration even in some cases where there's plenty
of disk space.

The number reported is highly sensitive to precise settings that the NFS
directory is mounted with.

Looks to me like the code assumes that f_frsize==f_bsize, and I hope that a
simple rewrite will make the code more robust (without breaking anything);
 I'm about to attach a proposed patch that uses f_bsize instead.
Comment 1 Dave Malcolm 2004-11-24 23:34:56 UTC
Created attachment 44428 [details] [review]
Patch to calculate diskspace from blocksize, rather than fragment size
Comment 2 Not Zed 2004-12-07 04:30:44 UTC
Created attachment 44469 [details]
stat vs statvfs tester
Comment 3 Not Zed 2004-12-07 05:00:38 UTC
hrm, ok this looks more complicated than it should be.

looking at the df source from coreutils, it seems to prefer frsize and
only fall back to bsize of frsize is 0.

however, also looking at the df sources, configure seems to disable
using statvfs when you're running on a glibc based system(!).  And
then there are 2 different basic statfs alternatives for bsd 4.3 and
4.4.  And the linux one doesn't seem to conform exactly to either.

From haip on irc:
<haip> notzed, on a linux machine with linux directory, the output is:
   Path
                                bsize    bavail    frsize
<haip>     /home/harry/tmp                -      4096   1137778
<haip> vfs /home/harry/tmp                -      4096   1137778      4096
<haip> on a linux machine with an mounted nfs solaris directory, the
output is
:
<haip>     Path                                 bsize    bavail    frsize
<haip>     /home/harry/tmp/firstserve     -      4096  39748571
<haip> vfs /home/harry/tmp/firstserve     -      4096  39748571      4096

so far so good, but:

<haip> notzed, it cound not compile on solaris because the defination of
statfs is different. After I comment the statfs part, the output is :"
<haip>     Path                                 bsize    bavail    frsize
<haip> vfs /export/home/haip              -      8192   6184225      1024
<haip> df -k output:
<haip> : /dev/dsk/c0t0d0s7    13495579 7176399 6184225    54%   
/export/home


so that means we can't use bsize as in the patch, that would be way
wrong in this case.

I really don't know what to do about this.  The bug on the redhat
server was worked around/resolved by changing mount options(!), but it
doesn't seem that changing mount options should have any effect on
statvfs.  "curious".

Comment 4 Burkhard 2005-01-23 08:29:29 UTC
Gnome system monitor and nautilus show the same behaviour. (wrong nfs
file system sizes)

See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141766
Comment 5 André Klapper 2005-04-14 12:50:51 UTC
hmm. is this still valid in 2.2?
Comment 6 Not Zed 2005-08-10 02:20:44 UTC
code hasn't changed, so i guess so.

really looks like a kernel/nfs issue to me.  it may not be possible to get
reliable size information.

I knew it was a stupid idea to ever expect we could, but nobody wanted to listen.
Comment 7 Burkhard 2005-08-10 12:35:36 UTC
Don't know about evolution, because evolution does report filesystem size only
in case of error. But gnome system monitor, which behaved the same way in Fedora
Core 3, now (FC 4, vers. 2.10.0) reports correct stats. So the error seems to
have vanished somehow.

Sorry, that I did not answer to grandparent, but by the time I was still with FC
3, and when I upgraded, everything was working and I just forgot.
Comment 8 André Klapper 2005-09-25 01:40:49 UTC
reassigning to harish; retargetting from very ancient 2.1 milestones to just
ancient 2.3 milestones. ;-)
Comment 9 André Klapper 2006-06-01 00:32:36 UTC
hmm... so can this be marked as obsolete nowadays? any comments? harish?
Comment 10 Harish Krishnaswamy 2006-07-31 09:06:02 UTC
This bug *is* obsolete and appears to have been outside Evo even earlier. Resolving the bug.