> On April 5, 2018, 4:45 p.m., Akash Gupta wrote: > > 3rdparty/stout/include/stout/os/windows/ftruncate.hpp > > Line 36 (original), 41 (patched) > > <https://reviews.apache.org/r/66455/diff/1/?file=1992415#file1992415line45> > > > > ftruncate doesn't change the file offset, so make sure you store the > > original file offset and restore it. It's currently setting it to the eof > > of the new file.
> The file offset is not changed. Indeed, good catch. - Andrew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66455/#review200596 ----------------------------------------------------------- On April 4, 2018, 12: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, 12: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 > >
