Bug 2425 - smbclient -c 'cd subdir; dir' bug when 'host msdfs = yes'
Summary: smbclient -c 'cd subdir; dir' bug when 'host msdfs = yes'
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.11
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-09 03:32 UTC by Volker Lendecke
Modified: 2005-08-24 10:24 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Lendecke 2005-03-09 03:32:16 UTC 
This is weird. I run an smbd rev 5704. If I set 'host msdfs = yes' and try to
list a subdirectory of that smbd with smbclient, I get the top-level directory.

Reproduce: Simple smb.conf, simple share (no msdfs root). Create a subdir 'bla'
in the share.

Do an smbclient //localhost/share -c 'cd bla; dir', everything is fine.

Set 'host msdfs = yes' and the same smbclient command will show the top-level
directory. Is this only happening to me???

Volker
Comment 1 Gerald (Jerry) Carter (dead mail address) 2005-03-09 06:53:48 UTC 
reproduced against 3.0.12pre2-SVN-build-5657.
It's probably my bug.  Thanks.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-03-09 08:11:06 UTC 
The original commit msg for include/msdfs.h says:

revision 1.5.4.3
date: 2001-08-29 19:56:27 +0000;  author: kalele;  state: Exp;  lines: +11 -11
Windows 95/98 clients send DFS format pathnames without setting the DFS bit in
flg2. So you never really know how to resolve the pathname (as DFS or
as tcon-relative). This fix works around this problem.

I can't reproduce this behavior from a Windows 98 se client.
Change the RESOLVE_FINDFIRST_DFSPATH in smbd/trans2.c to just
RESOLVE_DFSPATH solves the issue and win98 still functions.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:24:58 UTC 
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.