If we use echo 1234 >> some-file
then Documentation says that the output is appended.
My guess is that, if some-file does not exist, then O_CREAT will make a new file. If >
was used, then O_TRUNC will truncate existing file.
In case of >>
:
Will the file be opened as O_WRONLY (or O_RDWR) and seeked to end and write operation is done , simulating O_APPEND ?
Or will the file be opened as O_APPEND , leaving it to the kernel to make sure appending happens ?
I am asking this because a conserver process is overwriting some markers inserted by echo, when the output file is from NFS mount point, & NFS Documentation says O_APPEND is not supported on server, so client kernel will have to handle it. I guess conserver process is using O_APPEND , but not sure of bash >>
on linux, hence asking the question here.
O_APPEND
isn't supported; the problem is it's emulated. On a local file system, several processes writing to the same file opened withO_APPEND
will never overwrite each other's data; on NFS,O_APPEND
is emulated by seeking to the end before writing, which leaves the possibility of race conditions. There's no way around this on NFS; each parallel writer needs to write its own file. The only way to work around this is setup a server process on the NFS server, have the loggers log to|nc server port
, and have the server append incoming data to the log.