----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66455/#review200524 -----------------------------------------------------------
Ship it! 3rdparty/stout/include/stout/os/windows/ftruncate.hpp Lines 36 (patched) <https://reviews.apache.org/r/66455/#comment281265> I left this comment on a different review, which this was then extracted on: "I'm fine with a truncate function not writing null bytes to the part of a file that was truncated. Truncate should be a fast operation, in my opinion :)" - John Kordich On April 4, 2018, 7:16 p.m., Andrew Schwartzmeyer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66455/ > ----------------------------------------------------------- > > (Updated April 4, 2018, 7:16 p.m.) > > > Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, > and Michael Park. > > > Bugs: MESOS-8692 > https://issues.apache.org/jira/browse/MESOS-8692 > > > Repository: mesos > > > Description > ------- > > This previously used the CRT API `_chsize_s()`, which required a CRT > integer file descriptor. Instead, we can achieve the same behavior by > first using `os::lseek()` (which uses `SetFilePointerEx()`) to seek > `length`, and then use `SetEndOfFile()` to truncate. The only > difference is that the file is not filled with null bytes when > expanded, but we do not seem to rely on this behavior. > > > Diffs > ----- > > 3rdparty/stout/include/stout/os/windows/ftruncate.hpp > fc4a8b5040d56fa9766687e44ce17fbe47d9e8f0 > > > Diff: https://reviews.apache.org/r/66455/diff/1/ > > > Testing > ------- > > > Thanks, > > Andrew Schwartzmeyer > >
