Re: surprise behavior #1: ENOENT for existing directories

Suresh Jayaraman <[email protected]>
Newsgroups gmane.linux.file-systems.cifs
Message-ID <[email protected]>
On 11/30/2009 06:53 PM, Jeff Layton wrote:
> On Mon, 30 Nov 2009 16:45:59 +0530
> Suresh Jayaraman <[email protected]> wrote:
> 
>> On 11/30/2009 07:46 AM, aaron brick wrote:
>>> i am having two intermittent problems with CIFS and am sending
>>> separate emails to the list for each. this paragraph is identical. my
>>> desktop runs debian and kernel 2.6.32rc7; i am mounting a filesystem
>>> from my synology NAS, running DSM 2.2-0942 and using ext3 & RAID5
>>> internally. the link is gigabit through cat5e and a netgear switch.
>>> the only CIFS dmesg entry i see is a couple of: "CIFS VFS: server
>>> 10.1.1.2 of type Samba 3.2.8 returned unexpected error on SMB posix
>>> open, disabling posix open support. Check if server update available."
>>> (FWIW, synology hasn't released a firmware with a more recent samba.)
>>>
>>>
>>> here, creating files within a directory sometimes fails with ENOENT as
>>> if the parent did not exist. this generally prevents me from using the
>>> shared filesystem for compilation. an example follows:
>>>
>>>
>>> 11:08 / > mount | grep nas
>>> //nas/data on /data type cifs (rw,mand)
>>> 11:08 / > cd data
>>> 11:08 /data > mkdir a
>>> 11:08 /data > mkdir a/b
>>> mkdir: cannot create directory `a/b': No such file or directory
>>> 11:08 /data > strace mkdir a/b |& grep mkdir
>>> execve("/bin/mkdir", ["mkdir", "a/b"], [/* 22 vars */]) = 0
>>> mkdir("a/b", 0777)                      = -1 ENOENT (No such file or directory)
>>> write(2, "mkdir: ", 7mkdir: )                  = 7
>>>
>>
>> I have not been able to reproduce this 2.6.31-rc1 against Samba 3.2.7. But a
>> quick look at the code suggests there could be a problem if we do this
>> sequence:
>>
>> POSIX open against Samba server < 3.3.1 (tcon->broken_posix_open will be set)
>> followed by a mkdir (will call CIFSPOSIXCreate). As we don't seem to check
>> whether the broken_posix_open is set, this might have led to this issue I think.
>>
>> Does the following patch (a quick, untested) fix the issue?
>>
>>
>>
>>  fs/cifs/inode.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>> index cababd8..f1e9ab6 100644
>> --- a/fs/cifs/inode.c
>> +++ b/fs/cifs/inode.c
>> @@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
>>  		return rc;
>>  	}
>>  
>> -	if ((pTcon->ses->capabilities & CAP_UNIX) &&
>> +	if (!tcon->broken_posix_open && tcon->unix_ext &&
>              ^^^^ should be "pTcon"
> 

Oops, sorry about the not even compile tested patch. Here is the
compile tested patch. Could you please test this one?


 fs/cifs/inode.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index cababd8..31be938 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
 		return rc;
 	}
 
-	if ((pTcon->ses->capabilities & CAP_UNIX) &&
+	if (!pTcon->broken_posix_open && pTcon->unix_ext &&
+	    (pTcon->ses->capabilities & CAP_UNIX) &&
 		(CIFS_UNIX_POSIX_PATH_OPS_CAP &
 			le64_to_cpu(pTcon->fsUnixInfo.Capability))) {
 		u32 oplock = 0;
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.