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