Hi linux-filesystem experts First, please apologize if this is the wrong place to ask this question -- we googled around a lot and couldn't find an answer, that's why we finally try it here. The actual cause of the question is our reasoning about the robustness of the openssh code. Every invocation of ssh possibly adds a line to the file $(HOME)/.ssh/known_hosts, and (contrary to our expectations) we couldn't find any explicit locking in the code. Instead, the ssh code just opens the file with O_APPEND, writes to the file, and closes it. We already conducted a simple test that tries to create a 'corrupted' known_host files by starting lots of ssh commands concurrently, but so far we could not observe corruption. We now wonder if this is just by luck or if a programmer can rely on this behaviour. The generalized question is: If two (or more) different processes open the same file on a !LOCAL! disk with O_APPEND, and then concurrently issue write() calls to store data into this file, is there any guarantee that the data of each single write() call are written 'atomically', or could it happen that the data of different write()s are mangled or one write() overwrites data already written ? To prevent misunderstandings, we assume that ALL writers have opended the file with O_APPEND, and all write calls return normally without being interrupted by a signal. The Posix standard states that adavancing the filepointer to the end of the file and the following execution of the write are performed atomically with O_APPEND, but as far as we grasp it does not state if the actual write is also atomic w.r.t. other concurrrent write calls. If there is some guarantee : - does a (perhaps filesystem dependent) limit for this guarantee exist ? (like the PIPE_BUF size limit when writing to a pipe), and is there a way to detect this limit programmatically ? - does this guarantee also hold, if several threads in one process write to a single file DESCRIPTOR concurrently ? - does this guarantee also hold for remote filesystems (nfs / smb) ? If the answer to the last question is 'no' : is there a simple way to programmatically detect whether the guarantee holds for a specific file ? Many thanks for any answers ! Kind regards, Martin Cornelius ************************************************ The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ************************************************ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
