EA regression in 3.2?
jra at samba.org
Sat Jan 10 04:05:27 GMT 2009
On Fri, Jan 09, 2009 at 04:19:50PM +0100, Corinna Vinschen wrote:
> while testing something in Cygwin on a Samba 3.2.4 share, I suddenly
> got a strange error I never encountered when testing on Samba 3.0.x
> Consider a share //server/share. On the Windows side I try to get
> a handle to the share and immediately ask for read access to the Extended
> Attributes, if available:
> status = NtCreateFile (&h,
> READ_CONTROL | FILE_READ_ATTRIBUTES | FILE_READ_EA,
> &attr, &io, NULL, 0, FILE_SHARE_VALID_FLAGS,
> FILE_OPEN_REPARSE_POINT | FILE_OPEN_FOR_BACKUP_INTENT,
> eabuf, easize);
> What I expect as status code is either STATUS_EAS_NOT_SUPPORTED if the
> share does not support EAs, or STATUS_SUCCESS if the Samba share supports
> EAs (with "ea support = yes" in smb.conf).
> That's what I get from my Samba 3.0.x shares, at least.
> What I get from my Samba 3.2 shares is either STATUS_EAS_NOT_SUPPORTED
> if EAs are not supported, or STATUS_INVALID_PARAMETER, if EAs are
> supported. That's somewhat surprising and, AFAICS, a bug.
> An interesting fact here is that I only get STATUS_INVALID_PARAMETER
> for the shares's root dir:
> //server/share ==> STATUS_INVALID_PARAMETER
> //server/share/file ==> STATUS_SUCCESS
> //server/share/subdir ==> STATUS_SUCCESS
> //server/share/subdir/file ==> STATUS_SUCCESS
> So the problem is restricted to the case where I try to open a share's
> root dir.
> Here's the question: Is that a regression or is that expected
> behaviour in 3.2? If it's expected, what's the reason?
Can you send a debug level 10 log from smbd showing this please.
More information about the samba-technical