t9pfuse: "fix" O_LARGEFILE on x86_64 linux (sqweek) - plan9port - [fork] Plan 9 from user space
git clone git://src.adamsgaard.dk/plan9port
Log
Files
Refs
README
LICENSE
---
commit 7dc6d2444c7d20d0413c247b1b67aee4504248ac
parent 55d98d64b8352383ba4653f4baf5dc109e434ca2
Author: Russ Cox 
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(-)
---
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  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