u9fs on the server side zsh; echo hello world >tmp zsh; echo hi >>tmp zsh; cat tmp hi lo world So it hasn't truncated the file, but has started writing at zero offset instead of the end of file. bash, dash, tcsh and zsh all exhibit the behaviour, but it works fine in p9p's rc (which I'd wager is thanks to lib9, as it explicitly seeks). strace says: bash: open("t", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 3 dash: open("t", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 3 tcsh: open("t", O_WRONLY|O_APPEND|O_LARGEFILE) = 3 zsh: open("t", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND, 0666) = 3 rc: open("t", O_WRONLY|O_LARGEFILE) = 5 _llseek(5, 0, [12], SEEK_END) = 0 -sqweek
FWIW - I believe this works fine on spfs, but I will verify. There is an easy fix on the client which is to do the seek, but that introduces a race condition. Still that may be preferred behavior to what you saw.
I'm not entirely convinced this can be considered a server side bug. Plan 9 doesn't even have an OAPPEND flag for open(), and the only mention you'll find of similar in its man pages is regarding append only files. rc seeks there aswell. Over 9p, I don't think you have a reliable way to communicate to the server at open() time that you want to append to a file. -sqweek
The open based append support is specific to 9p2000.u which uses the plan 9 append flag to signal the server to seek to the end of the file upon opening -- since spfs uses 9p2000.u it works fine there. Since you are using u9fs, it falls back to legacy mode and just discards the APPEND -- which is incorrect, as I said the fix on the client side is to do the seek, but that unfortunately introduces a race condition which is a flaw of the mismatch between the protocol and the POSIX semantics.
I finally got around to looking into why writes to libixp servers didn't work with v9fs. First reason is that libixp doesn't handle wstat yet, so the Twstat to truncate the file fails (not v9fs's fault). The second reason shows itself when you append instead of truncate - the APPEND is not in fact discarded, but propagated to the server in the Topen mode. The server I'm using doesn't know what to do with 128 (which it actually interprets as ODIRECT, following the p9p convention) so it returns an error. I'm using a 2.6.25 kernel now, and I still get the same behaviour as the original bug report so I've bumped the version. -sqweek
Patch is in my v9fs-devel branch and is being sent out to mailing lists today hopefully for inclusion before 2.6.26 goes final.
*** Bug 10668 has been marked as a duplicate of this bug. ***
Working in 2.6.26, thanks.