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" <[EMAIL PROTECTED]> 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.
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
