Re: dfs path construction fixup for / character in \\server\share component of dfs path

[Igor Mammedov <niallain@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

Jeremy Allison wrote:
> On Thu, Apr 24, 2008 at 12:04:06PM +0400, Igor Mammedov wrote:
> 
>> I'm doing the second call with a short path to get inode info
>> including server generated inode number. If not for the last 
>> then second call could be omitted and inode be filled with fake
>> values and locally generated ino.
>>
>> PS:
>> Windows server does not object against the second call and returns
>> info on the dfs junction point (as directory). 
>> More uniform behavior between different implementations would be
>> better for all.
> 
> Can you try this patch against the 3.2 code please. It should
> cause smbd to return a directory on the short QFILEINFO call.

Thanks for a patch, I've just tested it. Packets dumps are attached. 

Short summary:
1. unix extentions are disabled.  Works.
   * ls on the directory that has a dfs link "dfs2" shows that it is directory
   * second QPATHINFO on "\dfs2" returns that it is directory (pkts 28-29)

2. unix extentions are enabled. Works partially.
   * ls on the directory that has a dfs link "dfs2" shows that it is a link 
     (pkts 26-27). Would be nice if it was listed as directory here. 
   * second QPATHINFO on "\dfs2" returns that it is directory (pkts 36-37)

Traverse over DFS junction point now works in both both cases.


-- 

Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com





[-- Attachment #2: smb32.Jeremy_unix_ext_disabled.pcap --]
[-- Type: application/octet-stream, Size: 9561 bytes --]

[-- Attachment #3: smb32.Jeremy_unix_ext_enabled.pcap --]
[-- Type: application/octet-stream, Size: 14286 bytes --]