use of utimensat() and AT_SYMLINK_NOFOLLOW

[barsnick]

This is similar to comment #5 (comment) of issue #5, except that my kernel is new enough.

I'm have an old system with glibc 2.9 and kernel 2.6.27 (cough). utimensat() is indeed available, but not like your autoconf thinks it is, and AT_SYMLINK_NOFOLLOW also not quite so.

bindfs.c: In function 'bindfs_utimens':
bindfs.c:978: warning: implicit declaration of function 'utimensat'
bindfs.c:978: error: 'AT_SYMLINK_NOFOLLOW' undeclared (first use in this function)
bindfs.c:978: error: (Each undeclared identifier is reported only once
bindfs.c:978: error: for each function it appears in.)

Man pages such as these:
http://man7.org/linux/man-pages/man2/faccessat.2.html
http://man7.org/linux/man-pages/man2/utimensat.2.html
seem to hint at a certain condition:

      Since glibc 2.10:
          _POSIX_C_SOURCE >= 200809L
      Before glibc 2.10:
          _ATFILE_SOURCE

Perhaps that should be set. Anyway, if I add "-D_ATFILE_SOURCE" to my CFLAGS (probably CPPFLAGS, if you ask me), it compiles just fine for me.

Let me guess that the utimensat() autoconf test passes on my system, because the symbol is contained in my glibc (AC_CHECK_FUNC only checks the function's runtime availability). It just isn't declared in the headers without the above #define, and the macro is neither.

Other projects have created their own m4 rules for utimensat(), I'm not sure if this isn't overkill:
https://sourceforge.net/p/ltp/mailman/message/31694249/

[mpartel]

Thanks for this and #49.

I do have some interest in supporting these older systems, and it shouldn't be too burdensome long-term since bindfs doesn't change very often. No promises, but I'll try to at least take a proper look in the next few weeks. Ideally I'd have an old enough CI environment to maintain compatibility. I wonder if Travis's ubuntu Trusty is close enough..

[barsnick]

Indeed, systems like these are old (but perhaps valid in their own right). Until recently, certain LTS distributions such as RHEL5 and SLES10 had much older glibcs, but both seem to finally have reached their EOL. (Alas, commercial customers do buy extended support beyond the documented EOL.) Anyway, if it's not much of a pain or a hack, supporting old systems is always a nice thing, especially as bindfs is so valuable. (It should be part of the fuse core filesystems. ;-))