On Thu, Nov 11, 2010 at 9:05 AM, Allan McRae <allan@archlinux.org> wrote:
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...
This seems to explain it well: http://stackoverflow.com/questions/1653163/difference-between-statvfs-and-st... FreeBSD also seems to define the function and type elsewhere, so we might just need to be smarter about what header we include: http://www.cygwin.com/ml/cygwin-developers/2003-12/msg00020.html So we shouldn't be using statfs() if possible. What was the error, Nezmer? Compile output would have been nice; is it that the type and function aren't even defined? Can you grep /usr/include/ for us to see if statvfs is defined but needs some sort of #define to turn it on? -Dan