[linux-cifs-client] Re: cthon test progress
Jeff Layton
jlayton at redhat.com
Thu Sep 25 00:12:58 GMT 2008
On Wed, 24 Sep 2008 18:44:41 -0500
"Steve French" <smfrench at gmail.com> wrote:
> With LinuxExtensionsDisabled and this patch applied, now make it farther.
>
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index db091c5..ba0d9fa 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -19,7 +19,6 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
> #include <linux/fs.h>
> -#include <linux/stat.h>
> #include <linux/pagemap.h>
> #include <asm/div64.h>
> #include "cifsfs.h"
> @@ -1309,8 +1308,33 @@ int cifs_rename(struct inode *source_inode,
> struct dentry *source_direntry,
> info_buf_target->UniqueId))
> /* same file, POSIX says that this is a noop */
> goto cifs_rename_exit;
> - } /* else ... BB we could add the same check for Windows by
> - checking the UniqueId via FILE_INTERNAL_INFO */
> + } else {
> + __u64 src_inode_num;
> + __u64 target_inode_num;
> + cFYI(1, ("check hardlinks windows style on %s",
> + fromName));
> + rc = CIFSGetSrvInodeNumber(xid, pTcon,
> + fromName, &src_inode_num,
> + cifs_sb_source->local_nls,
> + cifs_sb_source->mnt_cifs_flags &
> + CIFS_MOUNT_MAP_SPECIAL_CHR);
> + if (rc)
> + goto unlink_target;
> +
> + rc = CIFSGetSrvInodeNumber(xid, pTcon,
> + toName, &target_inode_num,
> + cifs_sb_source->local_nls,
> + cifs_sb_source->mnt_cifs_flags &
> + CIFS_MOUNT_MAP_SPECIAL_CHR);
> + if (rc)
> + goto unlink_target;
> +
> + if ((src_inode_num != 0) &&
> + (src_inode_num == target_inode_num)) {
> + cFYI(1, ("inode numbers match - rename noop"));
> + goto cifs_rename_exit;
> + }
> + }
> unlink_target:
> /*
> * we either can not tell the files are hardlinked (as with
>
> The "special" connectathon tests now fails at:
>
> second check for lost reply on non-idempotent requests
> testing 50 idempotencies in directory "testdir"
> stat 1: bad file type/size 0102767/30
> special tests failed
>
>
Nice work.
It would also be nice to see the hardlink detection code code broken
out into a separate function. cifs_rename is getting pretty large and
unweildy and that seems like a good clean spot for an interface.
--
Jeff Layton <jlayton at redhat.com>
More information about the linux-cifs-client
mailing list