4 ms·

Not true AFAICT. (On Linux at least) Here are a couple of snippets from the man page: > If a write() requests that more bytes be written than there is room fo

Not true AFAICT. (On Linux at least) Here are a couple of snippets from the man page: > If a write() requests that more bytes be written than there is room for (for example, the file size limit of the process or the physical end of a medium), only as many bytes as there is room for shall be written. (Admittely disk full is pretty much an edge case.) > If write() is interrupted by a signal after it successfully writes some data, it shall return the number of bytes written.

Someone 11y ago
I think a slightly better way to describe this is "write() is atomic, but may not write the number of bytes asked to write." A possible workaround is to use a start of line marker and provide a way to detect broken lines. For example, if one starts every line with a 0x02 and ends it in a 0x03 (Start of Text/End of Text ASCII characters) and removes any such character from the text being logged, partly written log entries can be detected and ignored when reading the log. If one does that, one can just retry writing the entire line until write() indicates it wrote the entire buffer passed in.
- mjevans 11y ago
  I disagree. It is far better to use a String like approach and use a structure that includes the length of the next written object. I believe that a simple sacrifice of a little more storage would also make that easier to split out. Pre-pad the message up to pad size zeros and then a pseudo-random number of additional pad objects (1 to n). Next you would store either the offset of the start or end, as well as the length of the payload (start would probably be easier to verify). With that structure it should be difficult to craft a payload message that looked like a valid message for the log.
  - Someone 11y ago
    I don't quite understand what approach you are advocating, but for me "it should be difficult to craft a payload message that looked like a valid message for the log." is not good enough for a system service.
    - mjevans 11y ago
      This is a back of the napkin grade design; refine it and/or develop a proof for your specific use case. Can you see any way it would be obviously incorrect? I could not when I wrote it, but I did not take the much greater effort of /proving/ it was a correct design. (which much like crypto algorithms, should also be done on an implementation by implementation basis)
- lomnakkus 11y ago
  You proposed > write() is atomic, but may not write the number of bytes asked to write. as an alternative formulation, but I'm not sure what that's even supposed to mean, semantically. "Atomic" literally means "indivisible" (well, "cannot cut" or "un-cuttable"). So either "all of it" or "none of it". Can you expound?

Someone 11y ago

I think a slightly better way to describe this is "write() is atomic, but may not write the number of bytes asked to write." A possible workaround is to use a start of line marker and provide a way to detect broken lines. For example, if one starts every line with a 0x02 and ends it in a 0x03 (Start of Text/End of Text ASCII characters) and removes any such character from the text being logged, partly written log entries can be detected and ignored when reading the log. If one does that, one can just retry writing the entire line until write() indicates it wrote the entire buffer passed in.

mjevans 11y ago
I disagree. It is far better to use a String like approach and use a structure that includes the length of the next written object. I believe that a simple sacrifice of a little more storage would also make that easier to split out. Pre-pad the message up to pad size zeros and then a pseudo-random number of additional pad objects (1 to n). Next you would store either the offset of the start or end, as well as the length of the payload (start would probably be easier to verify). With that structure it should be difficult to craft a payload message that looked like a valid message for the log.
- Someone 11y ago
  I don't quite understand what approach you are advocating, but for me "it should be difficult to craft a payload message that looked like a valid message for the log." is not good enough for a system service.
  - mjevans 11y ago
    This is a back of the napkin grade design; refine it and/or develop a proof for your specific use case. Can you see any way it would be obviously incorrect? I could not when I wrote it, but I did not take the much greater effort of /proving/ it was a correct design. (which much like crypto algorithms, should also be done on an implementation by implementation basis)
lomnakkus 11y ago
You proposed > write() is atomic, but may not write the number of bytes asked to write. as an alternative formulation, but I'm not sure what that's even supposed to mean, semantically. "Atomic" literally means "indivisible" (well, "cannot cut" or "un-cuttable"). So either "all of it" or "none of it". Can you expound?