commit 7dc6d2444c7d20d0413c247b1b67aee4504248ac parent 55d98d64b8352383ba4653f4baf5dc109e434ca2 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(-)
diff --git 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