From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve French" Subject: Re: dfs path construction fixup for / character in \\server\share component of dfs path Date: Fri, 23 May 2008 20:33:32 -0500 Message-ID: <524f69650805231833w4e567fecx7a90f9edf02ceb26@mail.gmail.com> References: <524f69650804181603x201f220as14cfd72eaeba5d48@mail.gmail.com> <480F4797.8020100@gmail.com> <20080423191150.GG10791@samba1> <20080423191906.GH10791@samba1> <48103EF6.7010004@gmail.com> <20080425211658.GB21342@samba1> <481478E4.3080100@gmail.com> <20080428185140.GC25413@samba1> <48342A5C.9060000@gmail.com> <20080524004605.GB13893@jeremy-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Igor Mammedov" , "Q (Igor Mammedov)" , linux-fsdevel , linux-cifs-client@lists.samba.org To: "Jeremy Allison" Return-path: Received: from nf-out-0910.google.com ([64.233.182.190]:11157 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752531AbYEXBde (ORCPT ); Fri, 23 May 2008 21:33:34 -0400 Received: by nf-out-0910.google.com with SMTP id d3so460069nfc.21 for ; Fri, 23 May 2008 18:33:32 -0700 (PDT) In-Reply-To: <20080524004605.GB13893@jeremy-laptop> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, May 23, 2008 at 7:46 PM, Jeremy Allison wrote: > On Wed, May 21, 2008 at 05:57:48PM +0400, Igor Mammedov wrote: >> >> Magic is really sucks. Because of DFS junction point >> is symlink in samba, when unix ext. is on, we had to do >> that magic thing in the kernel code. >> Now we have following behavior: >> 1. when client makes 'ls' for the first time on the >> directory with DFS links, 'ls' shows them as symlinks. >> 2. when we follow through a such 'symlink', it finely >> becomes a directory. >> That magic!!! >> IMHO: >> For a client the way better to see a directory from the start. >> (common code for handling this case for MS and Samba servers) >> and no magic at all. > > I can easily do this in the server, the problem is > how we define what is "correct" from the client > view with the UNIX extensions turned on. > > The problem is the Samba implementation > is bleeding out onto the wire here. As we're > stuck with it for the time being we have to > make the best of it. Trouble is, I'm not > sure what exactly the right decision is > here.. I don't know what is best either ... but whatever we do we should be careful not to hurt performance ... I would like to know what happens on: readdir of a directory contains a DFS "symlink" (followed by lookup of the symink inode which is cached) followed by get sym link info. Does that return STATUS_PATH_NOT_COVERED and everything works ...? -- Thanks, Steve