call_trans2qfilepathinfo without FLAGS2_DFS_PATHNAMES

[Jeremy Allison]

On Wed, Dec 16, 2009 at 09:56:30AM +0800, Tom Shaw wrote:
> Hi
> 
> On trying to upgrade from 3.0.23d to 3.4.3 on Solaris 10, I'm running
> into exactly the same symptoms reported in bug 5106:
> 
> https://bugzilla.samba.org/show_bug.cgi?id=5106
> 
> If a client (Windows XP SP3 or Windows Server 2003 SP2) has recently
> accessed a file share prior to the upgrade, then after the upgrade
> they are no longer able to access that share. The failure to access is
> associated with the client sending Trans2 QUERY_PATH_INFO with the
> path equal to the name of the share, e.g. "server\sharename", with
> FLAGS2_DFS_PATHNAMES not set. Samba interprets this as a Unix file
> lookup, fails to find a directory called "server/sharename", then
> returns NT_STATUS_OBJECT_PATH_NOT_FOUND.
> 
> I can consistently work around this problem in my test environment by
> rebooting the Windows client; this is the only way I've found to get
> the clients accessing the shares properly again. However, the
> production environment has hundreds of users, over 200 desktop PCs,
> several Citrix server farms, and Windows servers, all of which rely on
> these shares - I'd very much prefer not to need to reboot all of these
> systems when the upgrade is performed in production.
> 
> I'm after a practical solution - whether a server-side patch or some
> way to poke the Windows clients non-disruptively to allow them to deal
> with the upgrade.

Looking at that bug there was never a satisfactory resolution
as to what caused the client to issue a buggy call.

It looks like a client bug, especially if they behave after
rebooting. Can you get debug level 10 logs/wireshare traces
at will ?

If so I might be able to cobble together an (evil) server-side
patch for this but I'm not sure it'll go into mainline code
as it would slow down all non-dfs qpathinfo calls.

Jeremy.