On Tue,  5 Mar 2013 19:25:57 +0000
Sachin Prabhu <[email protected]> wrote:

> Instead of remapping ETXTBSY errors to EBUSY in cifs_unlink, replace all
> cases of ETXTBSY in cifs_rename_pending_delete() with EBUSY.
> 
> Signed-off-by: Sachin Prabhu <[email protected]>
> ---
>  fs/cifs/inode.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index fee2d40..0ab0328 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1034,7 +1034,7 @@ cifs_rename_pending_delete(const char *full_path, 
> struct dentry *dentry,
>                                  cifs_sb->mnt_cifs_flags &
>                                           CIFS_MOUNT_MAP_SPECIAL_CHR);
>       if (rc != 0) {
> -             rc = -ETXTBSY;
> +             rc = -EBUSY;
>               goto undo_setattr;
>       }
>  
> @@ -1053,7 +1053,7 @@ cifs_rename_pending_delete(const char *full_path, 
> struct dentry *dentry,
>               if (rc == -ENOENT)
>                       rc = 0;
>               else if (rc != 0) {
> -                     rc = -ETXTBSY;
> +                     rc = -EBUSY;
>                       goto undo_rename;
>               }
>               cifsInode->delete_pending = true;
> @@ -1167,8 +1167,6 @@ psx_del_no_retry:
>                       if (rc == 0)
>                               cifs_drop_nlink(inode);
>               }
> -             if (rc == -ETXTBSY)
> -                     rc = -EBUSY;



This doesn't look quite right. If ->rename_pending_delete isn't set,
then rc will still stay -ETXTBSY. I think this is a good cleanup, but
we need to consider changing the mapping for
NT_STATUS_SHARING_VIOLATION to -EBUSY as well, and fix all of the
places that look for -ETXTBSY in the cifs code.


>       } else if ((rc == -EACCES) && (dosattr == 0) && inode) {
>               attrs = kzalloc(sizeof(*attrs), GFP_KERNEL);
>               if (attrs == NULL) {


-- 
Jeff Layton <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to