v3.1.4 Files/mv bug

v3.1.4 Files/mv bug

[Phil Pennock]

Hi, I'm not on this list, yada yada.  You know the drill.  Anyways...

Another issue for you.  In zsh v.3.1.4, the 'files' module, (built for
Linux/x86, but not really relevant), the 'mv' command doesn't handle
moving across devices.

Src/Modules/files.c shows that the implementation of mv is handled as a
special case of ln.  Hrm...

HTH HAND
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* !r y?

Re: v3.1.4 Files/mv bug

[Zefram]

Phil Pennock wrote:
>Another issue for you.  In zsh v.3.1.4, the 'files' module, (built for
>Linux/x86, but not really relevant), the 'mv' command doesn't handle
>moving across devices.

This is a deliberate feature.  The logic is that you can't actually move
files across devices, and the purpose of mv is to move files, so mv can't
move files across devices.  The historical versions that do a copy and
remove are actually providing behaviour radically different from what
mv is intended for.  If you want a copy and remove, rather than a move,
you can use cp and rm yourself.

-zefram

PATCH: v3.1.4 Files/mv bug is a feature

[Bart Schaefer]

On Oct 14, 10:48am, Zefram wrote:
} Subject: Re: v3.1.4 Files/mv bug
}
} Phil Pennock wrote:
} >In zsh v.3.1.4, the 'files' module ... the 'mv' command doesn't handle
} >moving across devices.
} 
} This is a deliberate feature.

That probably ought to be documented, then.

Index: Doc/Zsh/mod_files.yo
===================================================================
--- mod_files.yo	1998/06/01 17:08:43	1.1.1.1
+++ mod_files.yo	1998/10/14 14:45:04
@@ -48,6 +48,12 @@
 The tt(-i) option causes the user to be queried about replacing
 any existing files.  The tt(-f) option causes any existing files to be
 silently deleted, without querying.  tt(-f) takes precedence.
+
+Note that this tt(mv) command performs renaming only.  It cannot move
+files across devices.  This is a deliberate feature.  Files can only
+be copied across devices, not truly moved, and the purpose of tt(mv)
+is to move files.  If the desired action is copy followed by remove,
+use tt(cp) and tt(rm).
 )
 findex(rm)
 item(tt(rm) [ tt(-dfirs) ] var(filename) ...)(

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: v3.1.4 Files/mv bug

[Dan Nelson]

In the last episode (Oct 14), Zefram said:
> Phil Pennock wrote:
> >Another issue for you.  In zsh v.3.1.4, the 'files' module, (built
> >for Linux/x86, but not really relevant), the 'mv' command doesn't
> >handle moving across devices.
> 
> This is a deliberate feature.  The logic is that you can't actually
> move files across devices, and the purpose of mv is to move files, so
> mv can't move files across devices.  The historical versions that do
> a copy and remove are actually providing behaviour radically
> different from what mv is intended for.  If you want a copy and
> remove, rather than a move, you can use cp and rm yourself.

I haven't used 3.1.* at all, so I'm just guessing here, but shouldn't
any builtin command that overrides an external command do _exactly_
what that external command was supposed to do?  Otherwise script
writers will have to use "command mv" or whatever, to guarantee that
they get a working "mv".

See the X/Open specification at
http://www.opengroup.org/onlinepubs/7908799/xcu/mv.html for a
description of at least one "standard" for mv, which allows
cross-device moves.

	-Dan Nelson
	dnelson@emsphone.com

Re: v3.1.4 Files/mv bug

[Phil Pennock]

Typing away merrily, Zefram produced the immortal words:
> This is a deliberate feature.  The logic is that you can't actually move
> files across devices, and the purpose of mv is to move files, so mv can't
> move files across devices.  The historical versions that do a copy and
> remove are actually providing behaviour radically different from what
> mv is intended for.  If you want a copy and remove, rather than a move,
> you can use cp and rm yourself.

So, just how POSIX-compliant is zsh aiming to be?  What does POSIX
actually require, anyway?

I can see that the extra logic in a shell is not as ... pleasant ... as
just a couple of system calls.  But, either the shell could do it
correctly or if the link(2) fails with EXDEV then automatically use the
one in the PATH.  This is a nice compromise, IMNSHO, since it allows
efficiency in many cases whilst still providing 'expected' (if not
actually required?) behaviour.

Alternatively, since they're both GPL'ed, just rip the code from the
FSF's GNU shell-utils or wherever mv(1) normally lives ...

Surely mv is /intended/ to be used as history mandates.  Hey, otherwise,
why not redefine O_RDONLY & O_WRONLY to be toggle-bits with
O_RDWR=(O_RDONLY|_WRONLY) on a new POSIX system.  It's correct.  Just
brain-dead and stupid.  Similarly for fudging mv.

Perplexed (and opinionated),
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* !r y?

Re: v3.1.4 Files/mv bug

[Zefram]

Phil Pennock wrote:
>So, just how POSIX-compliant is zsh aiming to be?  What does POSIX
>actually require, anyway?

POSIX does require the historical behaviour of mv.  However, as this
mv can only be used by taking explicit action (loading/autoloading
the module), I consider POSIX conformance to be less of an issue than
it is for the shell itself.  If someone wants to write a patch to add
the copy/remove fallback to the builtin mv, I don't have a problem with
putting it into the baseline; I just don't consider the current behaviour
to be broken.

>                                But, either the shell could do it
>correctly or if the link(2) fails with EXDEV then automatically use the
>one in the PATH.

Ugly.  There are a number of nasty issues here.

>Alternatively, since they're both GPL'ed, just rip the code from the
>FSF's GNU shell-utils or wherever mv(1) normally lives ...

zsh is not GPLed, and it's written much more neatly than most GNU
programs anyway.

-zefram

Re: v3.1.4 Files/mv bug

[Phil Pennock]

Typing away merrily, Zefram produced the immortal words:
> >Alternatively, since they're both GPL'ed, just rip the code from the
> >FSF's GNU shell-utils or wherever mv(1) normally lives ...
> 
> zsh is not GPLed, and it's written much more neatly than most GNU
> programs anyway.

Re GPL: oops!  Sorry.
Re cleanliness: yes, and I can see why you drew that from what I typed,
but when I use the term 'rip' I don't mean cut&paste... just algorithm
duplication and maybe noting postability issues affecting
implementation.

As re private conversation with Zefram: an option to zsh-mv to restrict
it to a rename, but defaulting to a compatible posix-mv is perhaps more
appropriate.

Thanks for reading this far.  :^)
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* !r y?

Re: v3.1.4 Files/mv bug

[Bart Schaefer]

On Oct 14,  6:46pm, Zefram wrote:
} Subject: Re: v3.1.4 Files/mv bug
}
} ... If someone wants to write a patch to add
} the copy/remove fallback to the builtin mv, I don't have a problem with
} putting it into the baseline; I just don't consider the current behaviour
} to be broken.

A builtin "cp" supporting the -a option (preserve ownership, permissions,
and mod times when possible) would be a useful addition to the files
module, and could be called from bin_mv() upon an EXDEV from rename().
That seems like the cleanest way to handle it.

Unfortunately, it'll be a while before I can focus on zsh for that long,
so I encourage someone else to beat me to it ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com