t9pfuse: "fix" O_LARGEFILE on x86_64 linux (sqweek) - plan9port - [fork] Plan 9 from user space
 (HTM) git clone git://src.adamsgaard.dk/plan9port
 (DIR) Log
 (DIR) Files
 (DIR) Refs
 (DIR) README
 (DIR) LICENSE
       ---
 (DIR) commit 7dc6d2444c7d20d0413c247b1b67aee4504248ac
 (DIR) parent 55d98d64b8352383ba4653f4baf5dc109e434ca2
 (HTM) Author: Russ Cox <rsc@swtch.com>
       Date:   Thu, 19 Jun 2008 18:56:56 -0400
       
       9pfuse: "fix" O_LARGEFILE on x86_64 linux (sqweek)
       
       Diffstat:
         M src/cmd/9pfuse/main.c               |      19 ++++++++++++++-----
       
       1 file changed, 14 insertions(+), 5 deletions(-)
       ---
 (DIR) diff --git a/src/cmd/9pfuse/main.c b/src/cmd/9pfuse/main.c
       t@@ -24,11 +24,20 @@
        #endif
        
        #ifndef O_LARGEFILE
       -#  if defined(__linux__)
       -#    define O_LARGEFILE 0100000  /* Sigh */
       -#  else
       -#    define O_LARGEFILE 0
       -#  endif
       +#  define O_LARGEFILE 0
       +#endif
       +
       +/*
       + * Work around glibc's broken <bits/fcntl.h> which defines
       + * O_LARGEFILE to 0 on 64 bit architectures.  But, on those same
       + * architectures, linux _forces_ O_LARGEFILE (which is always
       + * 0100000 in the kernel) at each file open. FUSE is all too
       + * happy to pass the flag onto us, where we'd have no idea what
       + * to do with it if we trusted glibc.
       + */
       +#if defined(__linux__)
       +#  undef O_LARGEFILE
       +#  define O_LARGEFILE 0100000
        #endif
        
        #ifndef O_CLOEXEC