Two append handles, one current end of file

Using an in-memory filesystem inside Emmux made small filesystem semantics matter. Code running against it expected familiar file behavior, including what append mode meant when more than one handle referred to the same file.

The relevant position was the file’s current end when the write happened—not a position that could already be stale by then.

Choose the position while holding the shared lock

I changed the append path in my AVFS fork to select the current end of the file while holding the shared node lock. That kept choosing the append position and writing against the same protected file state.

I added a regression case involving append handles so the behavior was captured directly, rather than relying on ordinary create-and-write tests to happen to exercise it.

This was one of a set of focused fixes needed by the embedded runtime. Others concerned sparse writes, links and open handles after unlink, but this change stayed narrow: append writes should use the current shared file state.

It was fork maintenance for a concrete dependency, not a new filesystem or a claim of complete operating-system compatibility.