As far as I can see, there is no problem with code being out of sync.
If you can point to specifics, please let me know,
since I'm about to release coreutils-7.5 upstream.
However, note that with glibc and a linux kernel, the stat program
always uses statfs, and not statvfs. This is a deliberate decision
taken at configure time. Details in comments here:
If someone does the legwork to determine whether that statvfs bug has been
fixed, and if so, since when, we should be able to write a configure test
to use glibc's statvfs when it's known not to be buggy.
As far as I can see, there is no problem with code being out of sync.
If you can point to specifics, please let me know,
since I'm about to release coreutils-7.5 upstream.
However, note that with glibc and a linux kernel, the stat program
always uses statfs, and not statvfs. This is a deliberate decision
taken at configure time. Details in comments here:
http:// git.savannah. gnu.org/ cgit/gnulib. git/tree/ m4/fsusage. m4#n50
However, the version of statvfs that forced us into this corner
dates back to 2003:
http:// git.sv. gnu.org/ cgit/gnulib. git/commit/ ?id=eda39b870b7 a849271
If someone does the legwork to determine whether that statvfs bug has been
fixed, and if so, since when, we should be able to write a configure test
to use glibc's statvfs when it's known not to be buggy.