today in "POSIX is a criminal mistake and I hate it personally"

the glibc behavior is the only one that really makes sense anyway

@whitequark things a developer almost definitely wants: a file where reading reads from a different place then where writes go to

@whitequark
I think reading when in append mode does not make sense

I don't know what I would expect tbh

also, since when can the read and the write position be different wtf???

@tthbaltazar in append mode there is no "write position" per se, anything you write gets appended to the end of file regardless of where the file pointer is

@charlotte I went to look up the documentation because this is exactly the behavior I want

@whitequark
w-whaat???

@tthbaltazar this is just the semantics of the open(O_APPEND) and write() syscalls

@whitequark @tthbaltazar this makes… some tiny amount of sense for very very specific scenarios

@whitequark @tthbaltazar it can be useful to ask where your write landed after the fact.

@pkhuong @tthbaltazar oh yeah that's true

@q @whitequark
I can only imagine log style formats, where you want to write from multiple processes

@tthbaltazar @q this is actually fairly common; the fact that the kernel guarantees that every write is appended (and you never overwrite anything) is a very nice guarantee you can't really get otherwise

@tthbaltazar @q @whitequark but wouldn't that result in data races or some other kind of race conditions?

@tanja @tthbaltazar @q not if you use O_APPEND (and respect its limitations)

@whitequark @tthbaltazar @q Does it make any sense in a setup where any `write` can legitimately be partial?

@robryk @tthbaltazar @q sometimes? if you deal with high reliability data storage, filesystems and their guarantees become quite squishy in practice (even for well-documented behaviors...) and you really need to understand exactly what the kernel is doing

@charlotte @whitequark pread() might be sufficient if you keep track of the offset yourself?

Apparently pwrite() also ignores O_APPEND (maybe useful for "write some data and then update a header"?) except on Linux:

"Bugs: POSIX requires that opening a file with the O_APPEND flag should have no affect on the location at which pwrite() writes data. However, on Linux, if a file is opened with O_APPEND, pwrite() appends data to the end of the file, regardless of the value of offset."

@whitequark @robryk @tthbaltazar @q and you can use encodings like https://pvk.ca/Blog/2021/01/11/stuff-your-logs/

@pkhuong @robryk @tthbaltazar @q oh this is very interesting reading—I use COBS heavily in my FPGA work and it's excellent