From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 18 Dec 2008 15:34:34 -0800
From: Roman Shaposhnik <rvs@sun.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <59EE20C6-0043-4517-ADDA-4BC5C4D24D74@sun.com>
MIME-version: 1.0
Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: [9fans] 9pfuse and O_APPEND
Topicbox-Message-UUID: 697becec-ead4-11e9-9d60-3106f5b1d025

I guess this is mainly a question for Russ: I'm using 9pfuse for a
proof-of-concept project here at Sun and it all works quite
well. My goal is to avoid the 9P2000.u route and use 9P2000
semantics  as much as possible, yet allow most of the POSIX
FS functionality to simply work.

In order to do that, I have to extend 9pfuse somewhat. In most
cases my code could be considered "complimentary" to the
core of 9pfuse, but there's one case which seems to be common
enough to  warrant some discussion and potential
changes to the core.

The question has to do with O_APPEND flag. POSIX apps
seem to use it quite frequently (most notably bash uses it
for the most basic of redirections  >>) but 9pfuse doesn't
really have any support for it:

main.c:_fuseopen
        /*
	 * Could translate but not standard 9P:
	 *	O_DIRECT -> ODIRECT
	 *	O_NONBLOCK -> ONONBLOCK
	 *	O_APPEND -> OAPPEND
	 */
	if(flags){
		fprint(2, "unexpected open flags %#uo", (uint)in->flags);
		replyfuseerrno(m, EACCES);
		return;
	}

So here's my question: is there any consensus on how to best
emulate it?

So far, I see the following choices for myself:
    * follow what v9fs does and emulate it with llseek(...SEEK_END).
Not ideal,
       since it doesn't always guarantee POSIX sematics, but way better
       than nothing.
    * emulate per-FID DMAPPEND by letting the server (which I also
control) accept Qid
       modifications on wstat. My understanding is that existing 9P
servers would simply
       reply with Rerror and I can then fallback onto llsek, perhaps.
Border-line abuse of
       the protocol.
    * reserve (unit)-1 offset in writes as an indication to append to
the end of the file. Really
       seems like an abuse of the protocol :-(

There's also a way for me to handle the situation the way I intend to
handle the
rest of POSIX goo: have a dedicated tree with a special aname. But in
case
of a so common operation it seems to be a bit of an overkill.

Thus, I'd really love to hear suggestions that might help integrate
that bit of code back into
the 9pfuse proper.

Thanks,
Roman.