From patchwork Mon Nov 30 16:44:22 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: surprise behavior #1: ENOENT for existing directories From: Suresh Jayaraman X-Patchwork-Id: 39821 Message-Id: <4B13F666.7090907@suse.de> To: linux-cifs-client@lists.samba.org Date: Mon, 30 Nov 2009 22:14:22 +0530 On 11/30/2009 06:53 PM, Jeff Layton wrote: > On Mon, 30 Nov 2009 16:45:59 +0530 > Suresh Jayaraman 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;