In article <20061017205533.GA28484@oak.schemamania.org>,
 <jklowden@schemamania.org> wrote:
>Hi,
>
>Today I tried to move a directory across file systems with mv(1).
>The source filesystem was ffs; the target was smbfs.  The directory
>tree had hundreds of large files.
>
>Then I changed my mind and pressed ^C.
>
>I did that because I noticed that it was copying one subtree of
>useless information (the .OLD directory).  To save time, I deleted
>the source files.  A moment later, I had an inkling of trouble when
>I got messages from mv, which I thought I had already killed with
>my ^C:
>
>  mv: dat/.OLD/f_company.1.dat.err: No such file or directory 
>  mv: dat/.OLD/f_security.1.asc: No such file or directory
>
>It's not every day I get messages from a dead process....
>
>When I tried to delete the target .OLD directory that  mv had
>created, I got a permission in error; when I tried to delete it
>from the Windows, it said the file [sic] was in use by another
>process.  Hmm.
>
>Back in NetBSD, ps(1) told me this:
>
>$ ps | grep mv 13718 p7 D      0:23.08 
>mv -PRp dat /usr/users/home[...]
>
>Hmm.  Those aren't documented options, and I hadn't typed them.
>
>No amount of 'kill -9' had any effect. In fact, process 13718 kept
>right on trucking, moving the other files.  I saw them appear on
>the target.
>
>Now, I understand that mv(1) is supposed to be atomic, and I know
>from the manpage moving files across filesystems employs magic
>under the covers.  But  think atomic is different from irreversible,
>and I think irreversible is suboptimal.
>
>Without looking at the code, I would guess that mv(1) is masking
>signals, perhaps in an effort to achieve atomicity.  Yet of course
>it can't make a non-atomic action (moving a set of files over a
>network) atomic, and preventing kill(8) from terminating the task
>looks to be more annoying than anything else.
>
>From my reading of the standard
>(http://www.opengroup.org/onlinepubs/009695399/utilities/mv.html),
>there's no atomic requirement.  It says only that errors should be
>handled in such a way that either the source or target tree should
>be intact (as in, don't delete the source tree until it's been
>copied completely).
>
>As far as I can tell, the only effect of my ^C was to prevent
>deletion of the source tree.  When the process finished, I seemed
>to have two complete copies.  Sort of an undocumented feature, in
>a way.
>
>Does anyone else think ^C should kill mv(1), first time, every
>time?

Yes, and it does... I don't know why it did not in your case.
If you look in the source for mv.c it just forks and execs cp and rm
when source and destination are not in the same filesystem.

christos