[issue15723] Python breaks OS' append guarantee on file writes

Change by Guido van Rossum : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Pyth

[issue15723] Python breaks OS' append guarantee on file writes

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15723] Python breaks OS' append guarantee on file writes

Changes by Ralf Schmitt : -- nosy: +schmir ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue15723] Python breaks OS' append guarantee on file writes

Charles-François Natali added the comment: I wouldn't rely on O_APPEND too much: - it won't work on NFS, and probably other non-local filesystems - it doesn't actually guarantee atomicity, because even though the the file offset and the write is done with locking, there is still the possibility

[issue15723] Python breaks OS' append guarantee on file writes

Antoine Pitrou added the comment: > Even if we write in chunks, if we are calling the OS write function > and O_APPEND is set, wouldn't be satisfying the condition? Or, > rather, the OS would be. That is, I don't really see a guarantee of > an *atomic* write in the quoted description. I'm not

[issue15723] Python breaks OS' append guarantee on file writes

R. David Murray added the comment: Even if we write in chunks, if we are calling the OS write function and O_APPEND is set, wouldn't be satisfying the condition? Or, rather, the OS would be. That is, I don't really see a guarantee of an *atomic* write in the quoted description. -- n

[issue15723] Python breaks OS' append guarantee on file writes

Poul-Henning Kamp added the comment: POLA = Principle Of Least Astonishment We use that a lot in architectural decision in FreeBSD :-) As I said: You deal with this as you see fit. If all python2 gets is a doc- or errata-notice, that's perfectly fine with me. I interpret "The writev() functio

[issue15723] Python breaks OS' append guarantee on file writes

Antoine Pitrou added the comment: > I have not tried io.open(), nor would I suspect most users would > realize that they needed to do so, in order to get the canonical > behaviour from an operation called "write" on a file opened in > "append" mode. The reason I'm asking is that open() is the sa

[issue15723] Python breaks OS' append guarantee on file writes

Poul-Henning Kamp added the comment: I have not tried io.open(), nor would I suspect most users would realize that they needed to do so, in order to get the canonical behaviour from an operation called "write" on a file opened in "append" mode. IMO: If pythons file.write() does not give the gu

[issue15723] Python breaks OS' append guarantee on file writes

Antoine Pitrou added the comment: Ah, sorry. I was stupidly looking for "atomic" and only found the pipe-specific remarks. (the other points remain, though :-)) -- ___ Python tracker __

[issue15723] Python breaks OS' append guarantee on file writes

Poul-Henning Kamp added the comment: Yes, it does: If the O_APPEND flag of the file status flags is set, the file offset shall be set to the end of the file prior to each write and no intervening file modification operation shall occur between changing the file offset and the write operation.

[issue15723] Python breaks OS' append guarantee on file writes

Antoine Pitrou added the comment: > When a file is opened in append mode, the operating system guarantees > that all write(2) system calls atomically appended their payload to the > file. Does it? I don't see such strong guarantees in http://pubs.opengroup.org/onlinepubs/9699919799/functions/w

[issue15723] Python breaks OS' append guarantee on file writes

New submission from Poul-Henning Kamp: When a file is opened in append mode, the operating system guarantees that all write(2) system calls atomically appended their payload to the file. At least on FreeBSD, Python breaks this guarantee, by chopping up large writes into multiple write(2) sysca