----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30609/#review73716 -----------------------------------------------------------
3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp <https://reviews.apache.org/r/30609/#comment120101> I was quite confused by the "ownsize" name, I think everyone will be too, since it's a term no one is familiar with. I'm more in favor of just size, but looks like you want to distinguish getting the size of the symbolic link or the actual linked file size. How about we add a option to follow the link or not? 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp <https://reviews.apache.org/r/30609/#comment120102> This method is calling lstat but logs stat, I think we should make it consistent. I propose let's fix this line to call lstat too. - Timothy Chen On Feb. 23, 2015, 7:02 a.m., Bernd Mathiske wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/30609/ > ----------------------------------------------------------- > > (Updated Feb. 23, 2015, 7:02 a.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and > Timothy Chen. > > > Bugs: MESOS-2072 > https://issues.apache.org/jira/browse/MESOS-2072 > > > Repository: mesos > > > Description > ------- > > This returns a file's size (on UNIXes as reported by lstat(), not stat()). It > is desired that in case of a link, the size of the link, not the size of the > referenced file, is returned. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp > 8a4fda97ee29c185471a69f60803efc193cbe922 > 3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp > 8a2d445c2edaa70da0e7b50e14ef88b2d9224a16 > > Diff: https://reviews.apache.org/r/30609/diff/ > > > Testing > ------- > > Wrote a simple test that creates a file and tests its size, and also checks > if a non-existing file yields an error. > > > Thanks, > > Bernd Mathiske > >
