----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44874/#review123802 -----------------------------------------------------------
3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/rmdir.hpp (line 70) <https://reviews.apache.org/r/44874/#comment186067> "don't". Also, we should use backticks for `FTS_COMFOLLOW` for consistency. Is that comment correct? ISTM that the relevant option that controls whether symbolic links are resolved is `FTS_LOGICAL` or `FTS_PHYSICAL`; `FTS_COMFOLLOW` is a special-case for the root path that is passed to `fts_open`. While we're at it, the OSX and Linux versions of the manpage for `fts_open` both claim that "either FTS_LOGICAL or FTS_PHYSICAL" *must* be specified. Seems like we're specifying neither, both here and in the other call-site to `fts_open` in `src/linux/cgroups.cpp`? - Neil Conway On March 15, 2016, 11:47 p.m., Jojy Varghese wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/44874/ > ----------------------------------------------------------- > > (Updated March 15, 2016, 11:47 p.m.) > > > Review request for mesos, Jie Yu and Neil Conway. > > > Repository: mesos > > > Description > ------- > > Added support for FTS_SLNONE in rmdir. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/rmdir.hpp > cf21e7fe458626c7533e596997cab3afdabb55f4 > 3rdparty/libprocess/3rdparty/stout/tests/os/rmdir_tests.cpp > 291a22b5aae53b0bc32ae18b9343ceb5a638b37b > > Diff: https://reviews.apache.org/r/44874/diff/ > > > Testing > ------- > > make check. > > > Thanks, > > Jojy Varghese > >
