[linux-cifs-client] NT4 server and the broken SetPathInfo level 257

[Naidu Bollineni]

I have seen similar failures - NTAP boxes fail to honor SET_PATH_INFO
level 260 on a path name.

Isn't it better to have a collection of this kind of qualification tests
to run after the share is mounted, but as part of the cifs_mount call,
to figure out what works and what does not. This can be retained in the
server structure and used always.

 

Naidu Bollineni

Senior Member Technical Staff

Kazeon Systems

naidu at kazeon.com

www.kazeon.com

________________________________

From: linux-cifs-client-bounces+naidu=kazeon.com at lists.samba.org
[mailto:linux-cifs-client-bounces+naidu=kazeon.com at lists.samba.org] On
Behalf Of Steven French
Sent: Monday, March 21, 2005 7:23 PM
To: samba-technical at lists.samba.org
Cc: linux-cifs-client at lists.samba.org
Subject: [linux-cifs-client] NT4 server and the broken SetPathInfo level
257

 

In chasing a bizarre problem to NT4 server in which server files for
which the cifs vfs changes the attributes for were getting marked
delete-on-close - I noticed that if I call level 257 SetPathInfo
(FILE_BASIC_INFO) to NT4 server (setting harmless attributes, if any,
such as 0x80 FILE_ATTRIBUTES_NORMAL), it fails with a not supported
error - then the file is "corrupted" (probably marked delete on close)
so that it can not be deleted locally. Further NTCreateX, SetFileInfo,
Close, SMB delete etc. all claim to work (but the SMB delete is a noop)
- but the file is not actually deleted and on the server trying to
delete the file gets an access denied. Very odd.

It looks like NT4 gets partway through handling level 0x101 of
SetPathInfo, messes up the attributes, returns error not supported, then
bails out. 

If the same level 0x101 buffer is passed to SetFileInfo (never calling
SetPathInfo) - everything works. If SetFileInfo is called after the
SetPathInfo (same buffer in both) - still acts weird.

Since this level works to Samba, Windows200x, etc. the trick is
recognizing servers which have the broken NT4 level 0x101 semantics -
and recognizing them early - before we actually try to send a
SetPathInfo level 0x101 to it (it is presumably too late if we wait
until one of the calls fails).

Uggh.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com