This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Call lstat() before setting flags to FTW_SLN


DJ Delorie <dj@redhat.com> writes:

> "Tulio Magno Quites Machado Filho" <tuliom@linux.vnet.ibm.com> writes:
>> POSIX.1-2008 doesn't describe this behavior explicitly in this case.
>
> See also https://bugzilla.redhat.com/show_bug.cgi?id=1422736
> and http://austingroupbugs.net/view.php?id=1121
>
> The spec also says "If FTW_PHYS is clear ... nftw() shall follow links
> instead of reporting them" but calling lstat() *is* reporting them,
> which the spec specifically forbids, if you read it that way.

Agreed.

> Hence, the clarification I requested from the Austin Group.  If the spec
> says we're not allowed to call lstat(), your patch is inappropriate.  If
> we are allowed to call lstat(), I think your patch is wrong - it may
> return FTW_NS for cases where lstat() might fail, where FTW_SLN should
> have been returned.  I can't think of any such cases, but I've been
> surprised before.  Also, cases where FTW_NS should be returned due to
> errors reading *non*dangling links should be preserved.

I think that's yet another interpretation of the spec.
So, we have to wait for their position.

> (I suspect calling LXSTAT() when we set the flag where your patch
>  deleted lines, should result in the desired behavior, though, possibly
>  with a test for !FTW_PHYS)

Ack.

Thanks for the references!

-- 
Tulio Magno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]