From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Q (Igor Mammedov)" Subject: Re: review 5, was Re: projected date for mount.cifs to support DFS junction points Date: Wed, 12 Mar 2008 12:28:55 +0300 Message-ID: <71bff3710803120228k3bba4491r5b689c55d1b82085@mail.gmail.com> References: <1199988975.7483.3.camel@gn2.draper.com> <20080113202144.GB24573@infradead.org> <47B5BFCF.60304@mail.ru> <47CD42DA.3070809@mail.ru> <20080308184127.GA1461@infradead.org> <71bff3710803081421l7f248614t44762d00bbf17af@mail.gmail.com> <20080310061434.GA20472@infradead.org> <524f69650803100920v4a10357ek70c6efc60dd9ceb0@mail.gmail.com> <71bff3710803110241x187c8e8ue62c400799e2aafa@mail.gmail.com> <524f69650803111514n4a61030xe62b15e02465e4ee@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1961531235==" Cc: linux-fsdevel , linux-cifs-client@lists.samba.org To: "Steve French" Return-path: In-Reply-To: <524f69650803111514n4a61030xe62b15e02465e4ee@mail.gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: linux-cifs-client-bounces+glfc-linux-cifs-client=gmane.org@lists.samba.org Errors-To: linux-cifs-client-bounces+glfc-linux-cifs-client=gmane.org@lists.samba.org List-Id: linux-fsdevel.vger.kernel.org --===============1961531235== Content-Type: multipart/alternative; boundary="----=_Part_7996_15549236.1205314135734" ------=_Part_7996_15549236.1205314135734 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Mar 12, 2008 at 1:14 AM, Steve French wrote: > After looking at the memleak in more detail - I am not convinced that > we should be altering the path on all calls to QueryPathInfo when > SMB_SHARE_IS_IN_DFS > SNIA CIFS-TR 1.0 spec: 3.6. DFS Pathnames A DFS pathname adheres to the standard described in the FileNames section. A DFS enabled client accessing a DFS share should set the Flags2 bit 12 in all name based SMB requests indicating to the server that the enclosed pathname should be resolved in the Distributed File System namespace. The pathname should always have the full file name, including the server name and share name. If the server can resolve the DFS name to a piece of local storage, the local storage will be accessed. If the server determines that the DFS name actually maps to a different server share, the access to the name will fail with the 32-bit status STATUS_PATH_NOT_COVERED (0xC0000257), or DOS error ERRsrv/ERRbadpath. > This seems excessive - only a small subset of the directories (or > files) in a share which is in the DFS namespace would require a second > lookup > In short words: We must send full UNC to get error -EREMOTE because server will return OK otherwise and we will get root share inode instead. This error is the only way to get the knowledge whether it is dfs path or not. That's why we send full path name when the tree is in DFS (SMB_SHARE_IS_IN_DFS). On the other hand: the second call to QueryPathInfo, when we already know that the path is in DFS, is a questionable matter. I attempt to fill "future mount point" inode with data returned by server for "link" path. Theoreticaly we can fill it with some static values here and avoid the second call. The question is "what values?" > > On Tue, Mar 11, 2008 at 4:41 AM, Q (Igor Mammedov) > wrote: > > Mem leak fix in inode.c > > > > > > -- > Thanks, > > Steve > ------=_Part_7996_15549236.1205314135734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Mar 12, 2008 at 1:14 AM, Steve French <smfrench@gmail.com> wrote:
After looking at the memleak in more detail - I am not convinced that
we should be altering the path on all calls to QueryPathInfo when
SMB_SHARE_IS_IN_DFS

SNIA CIFS-TR 1.0 spec:
3.6. DFS Pathnames
A DFS pathname adheres to the standard described in the FileNames section. A DFS enabled
client accessing a DFS share should set the Flags2 bit 12 in all name based SMB requests
indicating to the server that the enclosed pathname should be resolved in the Distributed File
System namespace. The pathname should always have the full file name, including the server
name and share name. If the server can resolve the DFS name to a piece of local storage, the
local storage will be accessed. If the server determines that the DFS name actually maps to a
different server share, the access to the name will fail with the 32-bit status
STATUS_PATH_NOT_COVERED (0xC0000257), or DOS error ERRsrv/ERRbadpath.


This seems excessive - only a small subset of the directories (or
files) in a share which is in the DFS namespace would require a second
lookup

In short words:
We must send full UNC to get error -EREMOTE because server
will return OK otherwise and we will get root share inode instead.
This error is the only way to get the knowledge whether it is dfs
path or not. That's why we send full path name when the tree is in
DFS (SMB_SHARE_IS_IN_DFS).

On the other hand: the second call to QueryPathInfo, when we already
know that the path is in DFS, is a questionable  matter.
I attempt to fill "future mount point" inode with data returned by
server for "link" path.  Theoreticaly we can fill it with some static values
here and avoid the second call. The question is "what values?"
 

On Tue, Mar 11, 2008 at 4:41 AM, Q (Igor Mammedov)
<qwerty0987654321@mail.ru> wrote:
> Mem leak fix in inode.c
>



--
Thanks,

Steve

------=_Part_7996_15549236.1205314135734-- --===============1961531235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-cifs-client mailing list linux-cifs-client@lists.samba.org https://lists.samba.org/mailman/listinfo/linux-cifs-client --===============1961531235==--