Re: mv does not behave like Solaris mv with respect to directory contents

[Haynes, Tom]

It will be version 6.4 of OnTap.

Thanks for making the change.

> Thanks for the patch and for your persistence.
> I've applied the following patch to coreutils-4.5.1
> (the successor to the fileutils package).
> This change will be in coreutils-4.5.2.
> 
>       In move mode, always first try to rename.  Before, upon failure to
>       rename a directory, this code would never attempt to rename any
>       other file in that directory, but would thenceforth always copy.
>       On some systems (NetApp version ??), renaming a directory may fail
>       with EXDEV, yet renaming files within that directory to a newly-
>       created destination directory succeeds.
>       * src/copy.c (copy_internal): Remove local, move_mode;
>       use x->move_mode instead.  Based on a patch from Tom Haynes.
> 
> Can you tell me the version of NetApp for which this makes a difference?
> Then I could fill in the `??' blank in the ChangeLog entry above.
> 
> Jim
> ---------------------
> Index: copy.c
> ===================================================================
> RCS file: /fetish/cu/src/copy.c,v
> retrieving revision 1.137
> diff -u -p -u -p -r1.137 copy.c
> --- copy.c    20 Jul 2002 20:06:41 -0000      1.137
> +++ copy.c    29 Sep 2002 08:38:08 -0000
> @@ -87,7 +87,7 @@ static int copy_internal PARAMS ((const 
>                                 int new_dst, dev_t device,
>                                 struct dir_list *ancestors,
>                                 const struct cp_options *x,
> -                               int move_mode,
> +                               int command_line_arg,
>                                 int *copy_into_self,
>                                 int *rename_succeeded));
>  
> @@ -801,14 +801,7 @@ copy_internal (const char *src_path, con
>    int ran_chown = 0;
>    int preserve_metadata;
>  
> -  /* move_mode is set to the value from the `options' parameter for the
> -     first copy_internal call.  For any subsequent recursive call, it must
> -     be zero.  This is because if we're moving (via mv) a hierarchy and
> -     end up having to recurse, it means the initial rename failed and so we
> -     are in the process of *copy*ing all of the parts, not renaming them.  */
> -  int move_mode = (command_line_arg ? x->move_mode : 0);
> -
> -  if (move_mode && rename_succeeded)
> +  if (x->move_mode && rename_succeeded)
>      *rename_succeeded = 0;
>  
>    *copy_into_self = 0;
> @@ -964,7 +957,7 @@ copy_internal (const char *src_path, con
>               }
>           }
>  
> -       if (move_mode)
> +       if (x->move_mode)
>           {
>             /* In move_mode, DEST may not be an existing directory.  */
>             if (S_ISDIR (dst_sb.st_mode))
> @@ -1127,9 +1120,7 @@ copy_internal (const char *src_path, con
>        return 0;
>      }
>  
> -  /* Note that this is testing the local variable move_mode, not
> -     the x->move_mode member.  */
> -  if (move_mode)
> +  if (x->move_mode)
>      {
>        if (rename (src_path, dst_path) == 0)
>       {
> 
>         
> "Haynes, Tom" <address@hidden> wrote:
> > As a followup, I've not seen a reply. ;>
> >
> > Here is a diff of my hack to get this working:
> >
> > cetialpha5.eng.netapp.com:> diff copy.c ../../fileutils-4.1.stock/src/copy.c
> > 124c124
> > <         const struct cp_options *x, int *copy_into_self, int move_mode)
> > ---
> >>         const struct cp_options *x, int *copy_into_self)
> > 156c156
> > <                           ancestors, &non_command_line_options, move_mode,
> > ---
> >>                           ancestors, &non_command_line_options, 0,
> > 920c920
> > <                   copy_into_self, move_mode))
> > ---
> >>                   copy_into_self))
> >
> >> I've looked at traces of both Solaris mv and the cut and paste GUI 
> >> operation
> >> on windows for behavior when a directory is moved.  In both cases, if
> >> the rename of the directory failed, then it is copied and then the entries
> >> are moved across one by one.  Both approaches try a move and not a copy.
> >> 
> >> In the GNU mv, if the directory rename fails, then the entries are all
> >> copied and no attempt is made to move them across.  As an optimization,
> >> I see why that would be there.  However, it does yield different behavior
> >> than other platforms.
> >> 
> >> In NetApp's NFS file servers, we have the concept of a quota tree, qtree, 
> >> which
> >> is a combination of a logical partition and quotas on a rooted subtree
> >> of a volume.  In the past, we disallowed moving files across qtrees. In
> >> our next release, we are going to allow moving files, but not directories,
> >> across qtrees.  With the typical client implementation of mv, the
> >> rename of the directory fails, so it gets copied to the new qtree,
> >> and then recursion tries to rename the files.  They get renamed and
> >> finally the original directory gets deleted.
> >> 
> >> This will not work with the 4.1 version of fileutils.
> 


-- 
Tom Haynes, cfb
address@hidden