Right. On 64-bit arches, linux forces the O_LARGEFILE (0x8000) flag in sys_open(). FUSE passes the flags along in fuse_send_open(), which makes its way to 9pfuse's _fuseopen(). _fuseopen() _tries_ to ignore the O_LARGEFILE flag, but on 64-bit arches, the userspace fcntl header <bits/fcntl.h> defines O_LARGEFILE as 0... even though the kernel still treats it as 0x8000. Friggin mess. Patch attached. -sqweek
On Fri, Mar 21, 2008 at 7:08 PM, John Soros <[EMAIL PROTECTED]> wrote: > Hi! > well, i have been having this error for quite a while with 9pfuse. on amd64 > linux (archlinux), i couldn't even ls a mounted directory, now that i have a > 32 bit system, ls works, but cp doesn't (i have no idea if it hasanything to > do with the arch, though). > this is how i mount sources with p9p: > $ 9fs sources > $ 9 mount `namespace`/sources /tmp/sources > then ls in a directory in /tmp/sources works, but when i try to copy, > attached is the output. > I'm open to testing whatever fixes you might suggest. > regs > John
Index: main.c =================================================================== RCS file: /cvs/plan9/src/cmd/9pfuse/main.c,v retrieving revision 1.14 diff -u -r1.14 main.c --- main.c 23 Nov 2007 21:28:33 -0000 1.14 +++ main.c 27 Mar 2008 02:47:39 -0000 @@ -24,11 +24,19 @@ #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
