There is an inconsistency seen when comparing the locking behaviour of CIFS clients on RHEL 4 U6 and RHEL 4 U8 on a share mounted from a Win2K3 server. ##### Reproducer: //win2k3_server/temp on /mnt type cifs (rw,mand) ### Win2k3 server //rhel4.6_server/public on /mnt2 type cifs (rw,mand) ### RHEL 4.6 samba ### FAIL test with w2k3 on RHEL 4.8. [root@AS4-8-test mnt]# ping localhost > aa & [1] 19763 [root@AS4-8-test mnt]# ls aa done [root@AS4-8-test mnt]# mv aa done/bb [root@AS4-8-test mnt]# ls bb done [root@AS4-8-test mnt]# ls -lR . .: total 4 -rwxrwSrwt 1 root root 2023 Apr 27 17:49 bb drwxrwxrwx 1 root root 0 Apr 21 18:46 done ./done: total 0 The `mv` command renames the file aa to bb. However it fails to move it to directory done. This behaviour is different on RHEL 4.6 where the move would fail with the error message mv: cannot move `aa' to `done/bb': Text file busy There is further confusion because the behaviour is different when the Samba share is a RHEL box. ### OK test with Samba on rhel [root@AS4-8-test mnt2]# ping localhost > aa & [1] 19793 [root@AS4-8-test mnt2]# ls aa done [root@AS4-8-test mnt2]# mv aa done/bb [root@AS4-8-test mnt2]# ls . done [root@AS4-8-test mnt2]# ls done/ bb Here the file is moved correctly. Desired behaviour: The behaviour should be the same in 4.8 as in 4.6. These are affecting applications which expect the original behaviour.
Hmm...can't seem to reproduce the issue against win2k8 so apparently it's less finicky about allowing someone to rename an open file. I think I see the problem though: if (rc == 0) { rc = CIFSSMBRenameOpenFile(xid, pTcon, srcfid, (const char *) to_dentry->d_name.name, cifs_sb->local_nls, cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); CIFSSMBClose(xid, pTcon, srcfid); } ...the above CIFSSMBRenameOpenFile is renaming to to_dentry->d_name.name, but should probably be using toPath instead. IIRC though there was a problem with that -- maybe renaming open files across directories isn't allowed? In any case, I'll have to set up a reproducer against a win2k3 host and see what can be done.
Created attachment 415448 [details] patch -- don't attempt busy-file rename unless source and target dir are same Proposed patch. Don't attempt a busy file rename unless the source and target dentries are in the same directory. The patch is pretty obvious so I think it makes sense. This will need to go upstream and into RHEL5, 6 etc...
Upstream post. https://patchwork.kernel.org/patch/103555/
Steve F. took the patch into his tree and we're planning to push this to stable too. I'll plan to propose internally soon.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Committed in 89.28.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
can reproduced on rhel4-u8: //10.66.65.195/win_share /mnt cifs rw,mand,noatime,nodiratime,unc=\\10.66.65.195\win_share,username=Administrator,uid=0,gid=0,file_mode=03767,dir_mode=0777,rsize=16384,wsize=57344 0 0 .live.[root@x86-64-4as-8-m1 mnt]# ls -l total 404 -rwxrwSrwt 1 root root 412150 Oct 21 2010 aa drwxrwxrwx 1 root root 0 Oct 21 2010 done .live.[root@x86-64-4as-8-m1 mnt]# mv aa done/bb .live.[root@x86-64-4as-8-m1 mnt]# ls -l total 408 -rwxrwSrwt 1 root root 415510 Oct 21 2010 bb drwxrwxrwx 1 root root 0 Oct 21 2010 done .live.[root@x86-64-4as-8-m1 mnt]# ls -lR .: total 408 -rwxrwSrwt 1 root root 415846 Oct 21 2010 bb drwxrwxrwx 1 root root 0 Oct 21 2010 done ./done: total 0 verified on kernel-2.6.9-89.45.EL on i386 and x86_64 arch: # mv aa done/bb mv: cannot move `aa' to `done/bb': Text file busy # uname -a Linux hp-sl2x160zg6-02.rhts.eng.bos.redhat.com 2.6.9-89.45.EL #1 Fri Oct 15 17:05:21 EDT 2010 i686 i686 i386 GNU/Linux
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0263.html