Andrew Schwartzmeyer created MESOS-8347:
-------------------------------------------

             Summary: Fix os::open() semantics on Windows
                 Key: MESOS-8347
                 URL: https://issues.apache.org/jira/browse/MESOS-8347
             Project: Mesos
          Issue Type: Bug
         Environment: Windows 10
            Reporter: Andrew Schwartzmeyer
            Assignee: Andrew Schwartzmeyer


The default semantics of {{open}} and {{fdopen}} on Windows is to use "text 
translation" mode, which means that for each end-of-line, instead of writing 
the data the user sent, it instead writes  a Windows-style CR/LF line ending.

[Text and Binary Mode File 
I/O|https://docs.microsoft.com/en-us/cpp/c-runtime-library/text-and-binary-mode-file-i-o]

[::open|https://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx]

This leads to problems in Mesos because all the existing code expects "POSIX 
semantics" (or really, the semantics where your data is written as it is 
given). To date, we've fixed half a dozen locations where we call Stout's 
{{os::open}} with an {{#ifdef __WINDOWS__}} to add the {{O_BINARY}} flag to 
disable text translation. At this point, we should instead just make this the 
default semantics of {{os::open}}, and address the possibility of needing text 
translation in the future (precedent shows it to be unlikely).

Things that were previously affected by this:

* protobuf::write
* net::download (which also uses fdopen directly and so needs {{wb}} mode)
* os::write (so we'd already made the decision that stout should behave this 
way)
* status_update_manager_process.hpp

We're making the conscious decision to _not_ use the function {{_set_fmode}} to 
change the default mode for newly opened files, because we would have to do 
this carefully for each process, and that probably means checking and setting 
it in stout anyway. Since we have stout (and thus a uniform way to access 
::open, though not ::fdopen, but it's only used once!), it's just as easy to 
add the {{O_BINARY}} flag to the call.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to