From 7dc6d2444c7d20d0413c247b1b67aee4504248ac Mon Sep 17 00:00:00 2001
From: Russ Cox <rsc@swtch.com>
Date: Thu, 19 Jun 2008 18:56:56 -0400
Subject: 9pfuse: "fix" O_LARGEFILE on x86_64 linux (sqweek)

---
 src/cmd/9pfuse/main.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

(limited to 'src/cmd/9pfuse')

diff --git a/src/cmd/9pfuse/main.c b/src/cmd/9pfuse/main.c
index 92124a73..a6c1df2f 100644
--- a/src/cmd/9pfuse/main.c
+++ b/src/cmd/9pfuse/main.c
@@ -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
-- 
cgit v1.2.3