commit 7dc6d2444c7d20d0413c247b1b67aee4504248ac
from: Russ Cox <rsc@swtch.com>
date: Thu Jun 19 22:56:56 2008 UTC

9pfuse: "fix" O_LARGEFILE on x86_64 linux (sqweek)

commit - 55d98d64b8352383ba4653f4baf5dc109e434ca2
commit + 7dc6d2444c7d20d0413c247b1b67aee4504248ac
blob - 92124a73af2d2c5f0b1a287cb544069d25827313
blob + a6c1df2f55bc969fb9c0edc930cdcaf58279fc9c
--- src/cmd/9pfuse/main.c
+++ src/cmd/9pfuse/main.c
@@ -24,13 +24,22 @@
 #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
 #  if defined(__linux__)
 #    define O_CLOEXEC 02000000  /* Sigh */