On 12/11/10 00:49, Nezmer wrote:
On Thu, Nov 11, 2010 at 04:46:44PM +0200, Nezmer wrote:
On Thu, Nov 11, 2010 at 09:09:27AM +1000, Allan McRae wrote:
On 11/11/10 07:29, Nezmer wrote:
But with those changes pacman did not like my ZFS pool.
From a bit of google, it looks like the statvfs call is probably returning EOVERFLOW on that so we can probably just assume LOTS of space and move on in those conditions...
Allan
That's over-simplification. This is the quick patch I needed to make this even compile.
diff --git a/lib/libalpm/diskspace.c b/lib/libalpm/diskspace.c index 51c25ed..f382d3c 100644 --- a/lib/libalpm/diskspace.c +++ b/lib/libalpm/diskspace.c @@ -80,7 +80,7 @@ static alpm_list_t *mount_point_list() endmntent(fp); #elif defined HAVE_GETMNTINFO int entries; - struct statvfs *fsp; + struct statfs *fsp;
entries = getmntinfo(&fsp, MNT_NOWAIT);
from /usr/include/sys/mount.h: int getmntinfo(struct statfs **, int);
And here comes the joys of various BSDs doing whatever they feel like... I have programmed based on the NetBSD man page which does use a statvfs struct...