DFS path construction

[Steve French-2]

The DFS patches are causing problems with Samba when the share is in
DFS and the path matches the form

/directory/subdir (or /directory/file)

It seems that when share is in DFS your code fixes up the
QueryPathInfo but not the rmdir and delete and various other path
based calls - so Samba sees the /directory/subdir in the path request
as /server/share instead and then a directory of "." which it can't
change into (Samba will return a "invalid handle" on rmdir of
/mnt/dir1/dir2)

My guess is that Windows would also have problems with this (for self
referrals apparently Windows can begin \\server\sharenames in UNC
paths in DFS requests with single slash instead of \\  perhaps this
would confuse windows if your "rmdir /mnt/dir1/dir2" which we will
send as SMBRmDir of \dir1\dir2 would fail if the share name is dir2
(and a valid server name is dir1).

In any case we should be sending the \\server\share\dir1\dir2 on the
remaining path based calls when share is in DFS ... right?

--
Thanks,

Steve
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeremy Allison]

On Tue, May 13, 2008 at 02:22:43PM -0500, Steve French wrote:

> The DFS patches are causing problems with Samba when the share is in
> DFS and the path matches the form
>
> /directory/subdir (or /directory/file)
>
> It seems that when share is in DFS your code fixes up the
> QueryPathInfo but not the rmdir and delete and various other path
> based calls - so Samba sees the /directory/subdir in the path request
> as /server/share instead and then a directory of "." which it can't
> change into (Samba will return a "invalid handle" on rmdir of
> /mnt/dir1/dir2)
>
> My guess is that Windows would also have problems with this (for self
> referrals apparently Windows can begin \\server\sharenames in UNC
> paths in DFS requests with single slash instead of \\  perhaps this
> would confuse windows if your "rmdir /mnt/dir1/dir2" which we will
> send as SMBRmDir of \dir1\dir2 would fail if the share name is dir2
> (and a valid server name is dir1).
>
> In any case we should be sending the \\server\share\dir1\dir2 on the
> remaining path based calls when share is in DFS ... right?

FYI:

http://lists-archives.org/samba/36879-problem-in-working-with-domain-dfs-links.html

Jeremy.
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Q (Igor Mammedov)-2]

Steve French wrote:

> The DFS patches are causing problems with Samba when the share is in
> DFS and the path matches the form
>
> /directory/subdir (or /directory/file)
>
> It seems that when share is in DFS your code fixes up the
> QueryPathInfo but not the rmdir and delete and various other path
> based calls - so Samba sees the /directory/subdir in the path request
> as /server/share instead and then a directory of "." which it can't
> change into (Samba will return a "invalid handle" on rmdir of
> /mnt/dir1/dir2)
>
> My guess is that Windows would also have problems with this (for self
> referrals apparently Windows can begin \\server\sharenames in UNC
> paths in DFS requests with single slash instead of \\  perhaps this
> would confuse windows if your "rmdir /mnt/dir1/dir2" which we will
> send as SMBRmDir of \dir1\dir2 would fail if the share name is dir2
> (and a valid server name is dir1).
>
> In any case we should be sending the \\server\share\dir1\dir2 on the
> remaining path based calls when share is in DFS ... right?
>

Generally MS works with path without tree name even if it in DFS enabled share,
However it wont report error EREMOTE if we try lookup on a dfs link.
So if share is dfs enabled we should use full path (including tree name) in
the calls where path names are used.


--

Best regards,

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




_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client