From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 18 Dec 2008 19:03:02 -0800
From: Roman Shaposhnik <rvs@sun.com>
In-reply-to: <dd6fe68a0812181557u28bf4c9drc1bdb417d6e4d1ed@mail.gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <31B5545F-E1A1-4526-8450-C81E9D16379D@sun.com>
MIME-version: 1.0
Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <59EE20C6-0043-4517-ADDA-4BC5C4D24D74@sun.com>
	<dd6fe68a0812181557u28bf4c9drc1bdb417d6e4d1ed@mail.gmail.com>
Subject: Re: [9fans] 9pfuse and O_APPEND
Topicbox-Message-UUID: 6a1a6c0a-ead4-11e9-9d60-3106f5b1d025

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);