cli_getattrE problem

[derrell at samba.org]

"Satwik Hebbar" <satwikh at calsoftinc.com> writes:

> I am using the samba-3.0.9 version and basically we use the libsmb client
> for our development work where we access files on CIFS shares. I wanted to
> be able to recognise whether a file has the ENCRYPTED, OFFLINE, REPARSE
> POINT, COMPRESSED and other such attributes set. I believe the
> cli_getattrE() function in the libsmb is meant to return this information as
> part of the 16 bit attribute field that it returns. This field gives correct
> info about the rest of the file attributes like TEMPORARY, SYSTEM, HIDDEN,
> etc.  but somehow does not have the rest of the bits set even when I call
> the function on a file which has been encrypted or compressed and so
> on. Could you tell me what I need to do to get this working? Is there some
> other function I need to use? I tried cli_getatr too with similar
> results.

This represents an interesting problem.  libsmbclient exports the smbc_
functions, which are intended to emulate POSIX functions.  Since there is
currently no POSIX function that would typically return ENCRYPTED, OFFLINE,
etc., there has been no need to have the internal cli_ functions return them.

Although I haven't looked into it at all, I suspect that there are bits that
must be passed in the request that would cause those bits to be returned in
the response.

> Should I be using the latest version of samba instead?

That wont likely help.  I don't believe we've done anything that would have
changed this behavior.

> I carried my tests against a WIN2K server.  I open the file with read and
> write permissions and in the backup-user context before making the getattrE
> call with the file handle I get.

If you'd like to look into what is required to have those bits returned from
the remote peer, I'd recommend that the external interface for retrieving them
be implemented as part of the smbc_getxattr() family of functions.  Adding a
"system.nt_attr" attribute name to return those extra fields would likely be
the best way to access them.

I've CC'ed this message to the samba-technical list.  Feel free to discuss
further.  If you provide a patch to implement this, I'll gladly look at
incorporating it.

Cheers,

Derrell