Re: [9fans] 9pfuse and O_APPEND

[Roman Shaposhnik]

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