Re: [9fans] 9pfuse and O_APPEND

[Roman Shaposhnik <rvs@sun.com>]

On Dec 18, 2008, at 3:57 PM, Russ Cox wrote:
> I would just seek to the end.

Got it. In that case, is there any reason the current version
of 9pfuse doesn't just skip O_APPEND (like it does with
O_LARGEFILE, etc.)? Since 9pfuse revalidate i_size
before writes that's the best one can do anyway(*)

The following patch seems to work for me. If there's
any reason for it NOT to be included in the Hg repo
please let me know:

--- main.c	2008-12-18 18:41:19.000000000 -0800
+++ src/cmd/9pfuse/main.c	2008-12-18 18:03:27.000000000 -0800
@@ -576,7 +576,7 @@
  	flags = in->flags;
  	openmode = flags&3;
  	flags &= ~3;
-	flags &= ~(O_DIRECTORY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC);
+	flags &= ~(O_DIRECTORY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_APPEND);
  	if(flags & O_TRUNC){
  		openmode |= OTRUNC;
  		flags &= ~O_TRUNC;

> That's fine unless you have multiple
> programs writing O_APPEND simultaneously,
> in which case you are asking for trouble.


Agreed. Now, here's a bit that I still don't quite
understand: Plan9 does have DMAPPEND on
a per-Qid basis. Why was it decided not to
have it on a per-Fid basis (which would match
POSIX semantics 100%)?

The way I understand -- DMAPPEND is just a hint
to the server to *alway* ignore the offset in
incoming writes. It seems that ignoring offsets
in writes for the Fids that asked for it wouldn't be
much more difficult, would it?

Thanks,
Roman.

(*) After some close examination of the 2.6.27 kernel I actually
wonder why v9fs guys
do an explicit seek in there open.

P.S. Its not different clients I'm worried about. Its something
like this within a single broken client:

     int fd = open("/tmp/test.txt", O_RDWR|O_APPEND);
     write(fd, "12345", 5);
     lseek(fd, 1, 0);
     write(fd, "00000", 5);