2) To undo the patch that introduces check_f_blocks_size, because
- on MacOS X 10.7 it is not needed any more after 1),
- on AIX and Cywin it causes non-POSIX API to be used for no reason,
- it kills portability to Interix 3.5.
Slight correction: It is still needed after 1), at least on MacOS X 10.5.
But only on MacOS X. So here's the proposed patch 2. Verified on AIX and
Cygwin; I don't have access to an Interix machine.
2011-07-23 Bruno Haible br...@clisp.org
fsusage: Restore previous behaviour on AIX, Cygwin, Interix.
* m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Enforce a 64-bit struct statvfs
f_blocks field only on MacOS X.
*** m4/fsusage.m4.orig Sat Jul 23 16:44:07 2011
--- m4/fsusage.m4 Sat Jul 23 16:42:32 2011
***
*** 62,75
Do not use Tru64's statvfs implementation
#endif
- #include limits.h
#include sys/statvfs.h
- /* Reject implementations, such as MacOS X 10.7, where f_blocks is a
-32-bit quantity; that commonly limits file systems to 4 TiB, a
-ridiculously small limit these days. */
struct statvfs fsd;
int check_f_blocks_size[sizeof fsd.f_blocks * CHAR_BIT = 32 ? -1 : 1];
]],
[[statvfs (0, fsd);]])],
[fu_cv_sys_stat_statvfs=yes],
--- 62,80
Do not use Tru64's statvfs implementation
#endif
#include sys/statvfs.h
struct statvfs fsd;
+
+ #if defined __APPLE__ defined __MACH__
+ #include limits.h
+ /* On MacOS X = 10.5, f_blocks in 'struct statvfs' is a 32-bit quantity;
+ that commonly limits file systems to 4 TiB. Whereas f_blocks in
+ 'struct statfs' is a 64-bit type, thanks to the large-file support
+ that was enabled above. In this case, don't use statvfs(); use statfs()
+ instead. */
int check_f_blocks_size[sizeof fsd.f_blocks * CHAR_BIT = 32 ? -1 : 1];
+ #endif
]],
[[statvfs (0, fsd);]])],
[fu_cv_sys_stat_statvfs=yes],
--
In memoriam Adam Czerniaków http://en.wikipedia.org/wiki/Adam_Czerniaków