[SCM] Samba Shared Repository - branch master updated
bj at SerNet.DE
Sat Jun 16 14:17:00 MDT 2012
On 2012-06-15 at 16:29 -0700 Jeremy Allison sent off:
> > s3: handle non-POSIX compliant Tru64, NetBSD and FreeBSD errno on O_NOFOLLOW symlink open calls
> > or should we leave the NetBSD and FreeBSD platforms just broken? Actually these
> > two *want* to have broken platforms as they use different errno's than POSIX
> > demands *interntionally*. The POSIX errno ELOOP for O_NOFOLLOW open calls on
> > symlinks is clear and unambiguous. See http://gnats.netbsd.org/43154 for the
> > interesting NetBSD discussion on that.
> Do we need this as a patch in 3.6.x ?
> Just wondering....
I tested the case of the linux cifs client doing a o_nofollow open of a symlink
after doing this fix because I realized that the bigger issue here is actually
that we map ELOOP to NT_STATUS_OBJECT_PATH_NOT_FOUND. That means a posix client
that want to check for something to be a symlink by doing a o_nofollow open on
it it will fail because we say PATH_NOT_FOUND instead of
NT_STATUS_TOO_MANY_LINKS. I'm not sure if at other places the mapping of ELOOP
to PATH_NOT_FOUND is required, that's why I didn't fix that yet. Jeremy can you
tell something on that? The Linux cifs client doesn't suffer from the
misleading PATH_NOT_FOUND reply here because a o_nofollow open on client side
is being converted in a stat call over the wire. But other cifs client
implementations might fail here when they actually send an o_nofollow open over
And yes, adding this to libreplace would be an option. on the other hand
o_nofollow open where we evaluate the errno for ELOOP is very rarely used in
our code, actually only at one place in s3 and in one place in s4 for the posix
extension code I think. Is it worth extending libreplace for that?
More information about the samba-technical