On 2018-10-13, Al Viro wrote:
> > Pardon me, but... huh? The reason for your two calls of dirfd_path_init()
> > is,
> > AFAICS, the combination of absolute pathname with both LOOKUP_XDEV and
> > LOOKUP_BENEATH at the same time. That combination is treated as if the
> > pathname
> > had been re
On 2018-10-13, Al Viro wrote:
> First of all, dirfd_path_init() part should be in a separate commit. And I'm
> really not happy with the logics in there. dirfd_path_init() itself is
> kinda-sorta reasonable.
Sure, I can do that.
> It is equivalent to setting the starting point for
> relative p
On Sat, Oct 13, 2018 at 08:33:19AM +0100, Al Viro wrote:
> Pardon me, but... huh? The reason for your two calls of dirfd_path_init() is,
> AFAICS, the combination of absolute pathname with both LOOKUP_XDEV and
> LOOKUP_BENEATH at the same time. That combination is treated as if the
> pathname
>
On Tue, Oct 09, 2018 at 06:02:28PM +1100, Aleksa Sarai wrote:
First of all, dirfd_path_init() part should be in a separate commit. And I'm
really not happy with the logics in there. dirfd_path_init() itself is
kinda-sorta reasonable. It is equivalent to setting the starting point for
relative p
Add the following flags to allow various restrictions on path
resolution (these affect the *entire* resolution, rather than just the
final path component -- as is the case with most other AT_* flags).
The primary justification for these flags is to allow for programs to be
far more strict about ho
5 matches
Mail list logo
