-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66455/#review200596
-----------------------------------------------------------




3rdparty/stout/include/stout/os/windows/ftruncate.hpp
Lines 34 (patched)
<https://reviews.apache.org/r/66455/#comment281366>

    I think Windows treats the "logical" file as zero-extended due to security 
reasons; it just doesn't actually write the 0s on disk. So, if you try reading 
from the extended region, you will get zeros.
    
    The only difference would be if you try seeking far into the extended 
region and then trying to write something. That `WriteFile` operation could 
take a lot of time, because it has to zero fill the previous bytes & write to 
disk.



3rdparty/stout/include/stout/os/windows/ftruncate.hpp
Line 36 (original), 41 (patched)
<https://reviews.apache.org/r/66455/#comment281365>

    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.


- Akash Gupta


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
> 
>

Reply via email to