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.
