> On March 16, 2016, 12:25 a.m., Neil Conway wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/rmdir.hpp, line 71 > > <https://reviews.apache.org/r/44874/diff/1/?file=1300428#file1300428line71> > > > > "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`?
Looks like we should use `FTS_PHYSICAL` in rmdir? - Jie ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44874/#review123802 ----------------------------------------------------------- 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 > >
