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

[Jim Meyering]

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.