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

Reply via email to