Report forwarded to debian-bugs-dist@lists.debian.org, Galen Hazelwood <galenh@micron.net>:
Bug#48038; Package fileutils.
debian-bugs-dist@lists.debian.orgGalen Hazelwood
Subject: Bug#48038: mv attempts to move directories with copy instead of rename
Reply-To: Zygo Blaxell , 48038@bugs.debian.org
Resent-From: Zygo Blaxell
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Galen Hazelwood
Resent-Date: Fri, 22 Oct 1999 17:18:02 GMT
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
X-Loop: owner@bugs.debian.org
Received: via spool by bugs@bugs.debian.org id=B.94061267825344
(code B ref -1); Fri, 22 Oct 1999 17:18:02 GMT
Message-Id: <199910221717.NAA14419@lain.wine.lnx>
From: Zygo Blaxell
To: Debian Bug Tracking System
X-Reportbug-Version: 0.37
X-Mailer: reportbug 0.37
Date: Fri, 22 Oct 1999 13:17:54 -0400
Package: fileutils
Version: 4.0-2.1
Severity: normal
File: /bin/mv
mv attempts to move directories when rename() fails. This causes code
which relied on the old behavior to determine whether files existed on the
same filesystem to fail in horrible ways.
There should either be an option to request this new behavior, or an
option to disable it.
-- System Information
Debian Release: potato
Architecture: i386
Kernel: Linux lain 2.2.13 #5 SMP Thu Oct 21 13:45:45 EDT 1999 i686
Versions of packages fileutils depends on:
ii libc6 2.1.2-5 GNU C Library: Shared libraries an
Acknowledgement sent to Zygo Blaxell <zblaxell@linuxmaster.hungrycats.org>:
New Bug report received and forwarded. Copy sent to Galen Hazelwood <galenh@micron.net>.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Zygo Blaxell
Subject: Bug#48038: Acknowledgement (mv attempts to move directories with copy instead of rename)
Message-ID:
In-Reply-To: <199910221717.NAA14419@lain.wine.lnx>
References: <199910221717.NAA14419@lain.wine.lnx>
X-Debian-PR-Message: ack 48038
Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received. It is being forwarded to the developers mailing list for
their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
Galen Hazelwood
If you wish to submit further information on your problem, please send
it to 48038@bugs.debian.org (and *not* to
bugs@bugs.debian.org).
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at submit) by bugs.debian.org; 22 Oct 1999 17:17:58 +0000
Received: (qmail 25339 invoked from network); 22 Oct 1999 17:17:58 -0000
Received: from internet.corel.ca (HELO lain.wine.lnx) (209.167.40.2)
by master.debian.org with SMTP; 22 Oct 1999 17:17:58 -0000
Received: (from zblaxell@localhost)
by lain.wine.lnx (8.9.3/8.9.3/Debian 8.9.3-6) id NAA14419;
Fri, 22 Oct 1999 13:17:54 -0400
Message-Id: <199910221717.NAA14419@lain.wine.lnx>
From: Zygo Blaxell
To: Debian Bug Tracking System
Subject: mv attempts to move directories with copy instead of rename
X-Reportbug-Version: 0.37
X-Mailer: reportbug 0.37
Date: Fri, 22 Oct 1999 13:17:54 -0400
Package: fileutils
Version: 4.0-2.1
Severity: normal
File: /bin/mv
mv attempts to move directories when rename() fails. This causes code
which relied on the old behavior to determine whether files existed on the
same filesystem to fail in horrible ways.
There should either be an option to request this new behavior, or an
option to disable it.
-- System Information
Debian Release: potato
Architecture: i386
Kernel: Linux lain 2.2.13 #5 SMP Thu Oct 21 13:45:45 EDT 1999 i686
Versions of packages fileutils depends on:
ii libc6 2.1.2-5 GNU C Library: Shared libraries an
Severity set to `wishlist'.
Request was from Michael Stone <mstone@debian.org>
to control@bugs.debian.org.
Received: (at control) by bugs.debian.org; 2 Nov 1999 22:38:16 +0000
Received: (qmail 27715 invoked from network); 2 Nov 1999 22:38:15 -0000
Received: from smtp1.erols.com (207.172.3.234)
by master.debian.org with SMTP; 2 Nov 1999 22:38:15 -0000
Received: from osgiliath.dhis.org (207-172-49-249.s249.tnt7.lnhva.md.dialup.rcn.com [207.172.49.249])
by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id RAA03723
for ; Tue, 2 Nov 1999 17:38:13 -0500 (EST)
Received: by osgiliath.dhis.org (Postfix, from userid 1000)
id 3557D545C7; Tue, 2 Nov 1999 17:24:14 -0500 (EST)
Date: Tue, 2 Nov 1999 17:24:14 -0500
From: Michael Stone
To: control@bugs.debian.org
Message-ID: <19991102172414.A5198@osgiliath.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre4i
X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88
Sender: mstone@justice.loyola.edu
close 45992
severity 48038 wishlist
merge 36911 40355
Changed Bug title.
Request was from Thomas Hood <jdthood@yahoo.co.uk>
to control@bugs.debian.org.
Received: (at control) by bugs.debian.org; 16 Dec 2005 19:15:16 +0000
From jdthood@yahoo.co.uk Fri Dec 16 11:15:16 2005
Return-path:
Received: from mailservice.tudelft.nl ([130.161.131.5])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EnL2y-000675-Ce
for control@bugs.debian.org; Fri, 16 Dec 2005 11:15:16 -0800
Received: from localhost (localhost [127.0.0.1])
by rav.antivirus (Postfix) with ESMTP id B365F233219
for ; Fri, 16 Dec 2005 20:14:45 +0100 (CET)
Received: from snurk.tiscali.nl (x081.decis.nl [130.161.177.81])
by mx2.tudelft.nl (Postfix) with ESMTP id 85F80233054
for ; Fri, 16 Dec 2005 20:14:45 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by snurk.tiscali.nl (Postfix) with ESMTP id ED668C01A9
for ; Fri, 16 Dec 2005 21:15:01 +0100 (CET)
Message-ID: <43A32045.4080104@yahoo.co.uk>
Date: Fri, 16 Dec 2005 21:15:01 +0100
From: Thomas Hood
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Debian Bug Tracking System
Subject: retitle
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at tudelft.nl
Delivered-To: control@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-2.0 required=4.0 tests=BAYES_00,ONEWORD autolearn=no
version=2.60-bugs.debian.org_2005_01_02
retitle 48038 coreutils: mv: Please provide option to disable attempt to move directories when rename() fails
stop
Message sent on to Zygo Blaxell <zblaxell@linuxmaster.hungrycats.org>:
Bug#48038.
Zygo Blaxell
X-Loop: owner@bugs.debian.org
Subject: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Reply-To: Thomas Hood , 48038-quiet@bugs.debian.org
Resent-To: Zygo Blaxell
Resent-Date: Tue, 20 Dec 2005 00:48:13 UTC
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Received: via spool by 48038-submitter@bugs.debian.org id=U48038.113503928431444
(code U ref 48038); Tue, 20 Dec 2005 00:48:13 UTC
Received: (at 48038-submitter) by bugs.debian.org; 20 Dec 2005 00:41:24 +0000
Received: from smtp-out2.tiscali.nl ([195.241.79.177])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EoVZE-0008B1-Jg
for 48038-submitter@bugs.debian.org; Mon, 19 Dec 2005 16:41:24 -0800
Received: from [82.171.132.56] (helo=82-171-132-56.dsl.ip.tiscali.nl)
by smtp-out2.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl)
id 1EoVZD-0005V3-Qu
for <48038-submitter@bugs.debian.org>; Tue, 20 Dec 2005 01:41:23 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
by 82-171-132-56.dsl.ip.tiscali.nl (Postfix) with ESMTP id D1B9FC00F8
for <48038-submitter@bugs.debian.org>; Tue, 20 Dec 2005 01:41:22 +0100 (CET)
Message-ID: <43A75332.8090406@yahoo.co.uk>
Date: Tue, 20 Dec 2005 01:41:22 +0100
From: Thomas Hood
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: 48038-submitter@bugs.debian.org
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2005_01_02
Can this wish report be closed now? Or are you still wishing for this feature?
I presume, at least, that the scripts that broke because of the change in mv's
behavior eventually got fixed. :)
--
Thomas Hood
Received: (at 48038-submitter) by bugs.debian.org; 20 Dec 2005 00:41:24 +0000
From jdthood@yahoo.co.uk Mon Dec 19 16:41:24 2005
Return-path:
Received: from smtp-out2.tiscali.nl ([195.241.79.177])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EoVZE-0008B1-Jg
for 48038-submitter@bugs.debian.org; Mon, 19 Dec 2005 16:41:24 -0800
Received: from [82.171.132.56] (helo=82-171-132-56.dsl.ip.tiscali.nl)
by smtp-out2.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl)
id 1EoVZD-0005V3-Qu
for <48038-submitter@bugs.debian.org>; Tue, 20 Dec 2005 01:41:23 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
by 82-171-132-56.dsl.ip.tiscali.nl (Postfix) with ESMTP id D1B9FC00F8
for <48038-submitter@bugs.debian.org>; Tue, 20 Dec 2005 01:41:22 +0100 (CET)
Message-ID: <43A75332.8090406@yahoo.co.uk>
Date: Tue, 20 Dec 2005 01:41:22 +0100
From: Thomas Hood
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: 48038-submitter@bugs.debian.org
Subject: closable?: "mv: Please provide option to disable attempt to move
directories when rename() fails"
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2005_01_02
Can this wish report be closed now? Or are you still wishing for this feature?
I presume, at least, that the scripts that broke because of the change in mv's
behavior eventually got fixed. :)
--
Thomas Hood
Information stored:
Bug#48038; Package fileutils.
-t
X-Loop: owner@bugs.debian.org
Subject: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Reply-To: Zygo Blaxell , 48038-quiet@bugs.debian.org
Resent-From: Zygo Blaxell
Resent-To:
Resent-Date: Tue, 20 Dec 2005 01:18:13 UTC
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Received: via spool by 48038-quiet@bugs.debian.org id=Q48038.113504099319898
(code Q ref 48038); Tue, 20 Dec 2005 01:18:13 UTC
Received: (at 48038-quiet) by bugs.debian.org; 20 Dec 2005 01:09:53 +0000
Received: from zblaxell.ott.istop.com
([66.11.173.28] helo=mokona.furryterror.org ident=meow)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EoW0j-00052g-NT; Mon, 19 Dec 2005 17:09:53 -0800
Received: from zblaxell by mokona.furryterror.org with local (Exim 3.36 #1 (Debian))
id 1EoW07-0001qt-00; Mon, 19 Dec 2005 20:09:11 -0500
Date: Mon, 19 Dec 2005 20:09:11 -0500
To: Thomas Hood , 48038-quiet@bugs.debian.org
Cc: 48038-submitter@bugs.debian.org
Message-ID: <20051220010911.GA25361@furryterror.org>
References: <43A75332.8090406@yahoo.co.uk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline
In-Reply-To: <43A75332.8090406@yahoo.co.uk>
User-Agent: Mutt/1.5.9i
From: Zygo Blaxell
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 20, 2005 at 01:41:22AM +0100, Thomas Hood wrote:
> Can this wish report be closed now? Or are you still wishing for this fe=
ature?
I am still wishing for this feature. It's been a long wait so far. ;-)
> I presume, at least, that the scripts that broke because of the change in=
mv's
> behavior eventually got fixed. :)
Not really...I just hit ^C whenever mv does the stupid things in my
old scripts. My new scripts don't use mv at all--they usually include
a Perl one-liner to invoke the rename() system call.
There's two cases of note: one where the source is a directory (so
mv copies the directory and attempts to remove the original), and one
where the source is a file but the file is in an unwritable directory
(so mv copies this file as in the directory case). The latter case is
especially annoying since the removal of the original file always fails,
leaving me with two copies to clean up. The latter case occurs quite
often for me when trying to 'mv' a file owned by another user from /tmp to
somewhere else--the old 'mv' would have given up after the rename() system
call fails, the new 'mv' acts like 'cp' but with more error messages.
The behavior seems to be mandated by some standards organization--everybody=
's
mv seems to have this annoying behavior now, not just GNU's. :-( =20
If 'mv' *must* have this behavior, it would be preferable if it tried
these in order:
1. rename(filea, fileb). If successful exit.
2. link(filea, fileb) followed by unlink(filea). If successful exit.
3. if and only if the error from the link was "invalid
cross-device link", copy (filea, fileb) followed by unlink(filea)
(possibly using recursive directory-copying code as mv does now).
If successful exit.
4. Exit with an error.
I would prefer to have an option for a "no-copy mode", where mv does
everything it does now, except that it gives up if it is forced to try
to copy anything.
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDp1m3gfmLGlazG5wRApsFAJ9bYmHJgd9+A7QYf3TE/Qa0xVTp6wCghjOL
Za53z3O1EW7eZItW0eGn7jY=
=+HoB
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
Acknowledgement sent to Zygo Blaxell <zblaxell@furryterror.org>:
Extra info received and filed, but not forwarded.
-t
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Zygo Blaxell
Subject: Bug#48038: Info received and FILED only
(was Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails")
Message-ID:
In-Reply-To: <20051220010911.GA25361@furryterror.org>
References: <20051220010911.GA25361@furryterror.org>
Precedence: bulk
X-Debian-PR-Message: ack-info-quiet 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Reply-To: 48038-quiet@bugs.debian.org
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the package
maintainers, but will accompany the original report in the Bug
tracking system. Please ensure that you yourself have sent a copy of
the additional information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 48038-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Received: (at 48038-quiet) by bugs.debian.org; 20 Dec 2005 01:09:53 +0000
From zblaxell@furryterror.org Mon Dec 19 17:09:53 2005
Return-path:
Received: from zblaxell.ott.istop.com
([66.11.173.28] helo=mokona.furryterror.org ident=meow)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EoW0j-00052g-NT; Mon, 19 Dec 2005 17:09:53 -0800
Received: from zblaxell by mokona.furryterror.org with local (Exim 3.36 #1 (Debian))
id 1EoW07-0001qt-00; Mon, 19 Dec 2005 20:09:11 -0500
Date: Mon, 19 Dec 2005 20:09:11 -0500
To: Thomas Hood , 48038-quiet@bugs.debian.org
Cc: 48038-submitter@bugs.debian.org
Subject: Re: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Message-ID: <20051220010911.GA25361@furryterror.org>
References: <43A75332.8090406@yahoo.co.uk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline
In-Reply-To: <43A75332.8090406@yahoo.co.uk>
User-Agent: Mutt/1.5.9i
From: Zygo Blaxell
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 20, 2005 at 01:41:22AM +0100, Thomas Hood wrote:
> Can this wish report be closed now? Or are you still wishing for this fe=
ature?
I am still wishing for this feature. It's been a long wait so far. ;-)
> I presume, at least, that the scripts that broke because of the change in=
mv's
> behavior eventually got fixed. :)
Not really...I just hit ^C whenever mv does the stupid things in my
old scripts. My new scripts don't use mv at all--they usually include
a Perl one-liner to invoke the rename() system call.
There's two cases of note: one where the source is a directory (so
mv copies the directory and attempts to remove the original), and one
where the source is a file but the file is in an unwritable directory
(so mv copies this file as in the directory case). The latter case is
especially annoying since the removal of the original file always fails,
leaving me with two copies to clean up. The latter case occurs quite
often for me when trying to 'mv' a file owned by another user from /tmp to
somewhere else--the old 'mv' would have given up after the rename() system
call fails, the new 'mv' acts like 'cp' but with more error messages.
The behavior seems to be mandated by some standards organization--everybody=
's
mv seems to have this annoying behavior now, not just GNU's. :-( =20
If 'mv' *must* have this behavior, it would be preferable if it tried
these in order:
1. rename(filea, fileb). If successful exit.
2. link(filea, fileb) followed by unlink(filea). If successful exit.
3. if and only if the error from the link was "invalid
cross-device link", copy (filea, fileb) followed by unlink(filea)
(possibly using recursive directory-copying code as mv does now).
If successful exit.
4. Exit with an error.
I would prefer to have an option for a "no-copy mode", where mv does
everything it does now, except that it gives up if it is forced to try
to copy anything.
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDp1m3gfmLGlazG5wRApsFAJ9bYmHJgd9+A7QYf3TE/Qa0xVTp6wCghjOL
Za53z3O1EW7eZItW0eGn7jY=
=+HoB
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
Message sent on to Zygo Blaxell <zblaxell@linuxmaster.hungrycats.org>:
Bug#48038.
Zygo Blaxell
X-Loop: owner@bugs.debian.org
Subject: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Reply-To: Zygo Blaxell , 48038-quiet@bugs.debian.org
Resent-To: Zygo Blaxell
Resent-Date: Tue, 20 Dec 2005 01:18:14 UTC
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Received: via spool by 48038-submitter@bugs.debian.org id=U48038.113504099319909
(code U ref 48038); Tue, 20 Dec 2005 01:18:14 UTC
Received: (at 48038-submitter) by bugs.debian.org; 20 Dec 2005 01:09:53 +0000
Received: from zblaxell.ott.istop.com
([66.11.173.28] helo=mokona.furryterror.org ident=meow)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EoW0j-00052g-NT; Mon, 19 Dec 2005 17:09:53 -0800
Received: from zblaxell by mokona.furryterror.org with local (Exim 3.36 #1 (Debian))
id 1EoW07-0001qt-00; Mon, 19 Dec 2005 20:09:11 -0500
Date: Mon, 19 Dec 2005 20:09:11 -0500
To: Thomas Hood , 48038-quiet@bugs.debian.org
Cc: 48038-submitter@bugs.debian.org
Message-ID: <20051220010911.GA25361@furryterror.org>
References: <43A75332.8090406@yahoo.co.uk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline
In-Reply-To: <43A75332.8090406@yahoo.co.uk>
User-Agent: Mutt/1.5.9i
From: Zygo Blaxell
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-CrossAssassin-Score: 2
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 20, 2005 at 01:41:22AM +0100, Thomas Hood wrote:
> Can this wish report be closed now? Or are you still wishing for this fe=
ature?
I am still wishing for this feature. It's been a long wait so far. ;-)
> I presume, at least, that the scripts that broke because of the change in=
mv's
> behavior eventually got fixed. :)
Not really...I just hit ^C whenever mv does the stupid things in my
old scripts. My new scripts don't use mv at all--they usually include
a Perl one-liner to invoke the rename() system call.
There's two cases of note: one where the source is a directory (so
mv copies the directory and attempts to remove the original), and one
where the source is a file but the file is in an unwritable directory
(so mv copies this file as in the directory case). The latter case is
especially annoying since the removal of the original file always fails,
leaving me with two copies to clean up. The latter case occurs quite
often for me when trying to 'mv' a file owned by another user from /tmp to
somewhere else--the old 'mv' would have given up after the rename() system
call fails, the new 'mv' acts like 'cp' but with more error messages.
The behavior seems to be mandated by some standards organization--everybody=
's
mv seems to have this annoying behavior now, not just GNU's. :-( =20
If 'mv' *must* have this behavior, it would be preferable if it tried
these in order:
1. rename(filea, fileb). If successful exit.
2. link(filea, fileb) followed by unlink(filea). If successful exit.
3. if and only if the error from the link was "invalid
cross-device link", copy (filea, fileb) followed by unlink(filea)
(possibly using recursive directory-copying code as mv does now).
If successful exit.
4. Exit with an error.
I would prefer to have an option for a "no-copy mode", where mv does
everything it does now, except that it gives up if it is forced to try
to copy anything.
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDp1m3gfmLGlazG5wRApsFAJ9bYmHJgd9+A7QYf3TE/Qa0xVTp6wCghjOL
Za53z3O1EW7eZItW0eGn7jY=
=+HoB
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
Received: (at 48038-submitter) by bugs.debian.org; 20 Dec 2005 01:09:53 +0000
From zblaxell@furryterror.org Mon Dec 19 17:09:53 2005
Return-path:
Received: from zblaxell.ott.istop.com
([66.11.173.28] helo=mokona.furryterror.org ident=meow)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EoW0j-00052g-NT; Mon, 19 Dec 2005 17:09:53 -0800
Received: from zblaxell by mokona.furryterror.org with local (Exim 3.36 #1 (Debian))
id 1EoW07-0001qt-00; Mon, 19 Dec 2005 20:09:11 -0500
Date: Mon, 19 Dec 2005 20:09:11 -0500
To: Thomas Hood , 48038-quiet@bugs.debian.org
Cc: 48038-submitter@bugs.debian.org
Subject: Re: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Message-ID: <20051220010911.GA25361@furryterror.org>
References: <43A75332.8090406@yahoo.co.uk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline
In-Reply-To: <43A75332.8090406@yahoo.co.uk>
User-Agent: Mutt/1.5.9i
From: Zygo Blaxell
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-CrossAssassin-Score: 2
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 20, 2005 at 01:41:22AM +0100, Thomas Hood wrote:
> Can this wish report be closed now? Or are you still wishing for this fe=
ature?
I am still wishing for this feature. It's been a long wait so far. ;-)
> I presume, at least, that the scripts that broke because of the change in=
mv's
> behavior eventually got fixed. :)
Not really...I just hit ^C whenever mv does the stupid things in my
old scripts. My new scripts don't use mv at all--they usually include
a Perl one-liner to invoke the rename() system call.
There's two cases of note: one where the source is a directory (so
mv copies the directory and attempts to remove the original), and one
where the source is a file but the file is in an unwritable directory
(so mv copies this file as in the directory case). The latter case is
especially annoying since the removal of the original file always fails,
leaving me with two copies to clean up. The latter case occurs quite
often for me when trying to 'mv' a file owned by another user from /tmp to
somewhere else--the old 'mv' would have given up after the rename() system
call fails, the new 'mv' acts like 'cp' but with more error messages.
The behavior seems to be mandated by some standards organization--everybody=
's
mv seems to have this annoying behavior now, not just GNU's. :-( =20
If 'mv' *must* have this behavior, it would be preferable if it tried
these in order:
1. rename(filea, fileb). If successful exit.
2. link(filea, fileb) followed by unlink(filea). If successful exit.
3. if and only if the error from the link was "invalid
cross-device link", copy (filea, fileb) followed by unlink(filea)
(possibly using recursive directory-copying code as mv does now).
If successful exit.
4. Exit with an error.
I would prefer to have an option for a "no-copy mode", where mv does
everything it does now, except that it gives up if it is forced to try
to copy anything.
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDp1m3gfmLGlazG5wRApsFAJ9bYmHJgd9+A7QYf3TE/Qa0xVTp6wCghjOL
Za53z3O1EW7eZItW0eGn7jY=
=+HoB
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
Information forwarded to debian-bugs-dist@lists.debian.org, Michael Stone <mstone@debian.org>:
Bug#48038; Package fileutils.
debian-bugs-dist@lists.debian.orgMichael Stone
X-Loop: owner@bugs.debian.org
Subject: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Reply-To: Thomas Hood , 48038@bugs.debian.org
Resent-From: Thomas Hood
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Michael Stone
Resent-Date: Tue, 20 Dec 2005 09:48:07 UTC
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Received: via spool by 48038-submit@bugs.debian.org id=B48038.11350719589551
(code B ref 48038); Tue, 20 Dec 2005 09:48:07 UTC
Received: (at 48038) by bugs.debian.org; 20 Dec 2005 09:45:58 +0000
Received: from mailservice.tudelft.nl ([130.161.131.5])
by spohr.debian.org with esmtp (Exim 4.50)
id 1Eoe4D-0002SE-JQ
for 48038@bugs.debian.org; Tue, 20 Dec 2005 01:45:57 -0800
Received: from localhost (localhost [127.0.0.1])
by rav.antivirus (Postfix) with ESMTP id D291F232EF2
for <48038@bugs.debian.org>; Tue, 20 Dec 2005 10:45:25 +0100 (CET)
Received: from 82-171-132-56.dsl.ip.tiscali.nl (x100.decis.nl [130.161.177.100])
by mx2.tudelft.nl (Postfix) with ESMTP id 5BEC1232EA9
for <48038@bugs.debian.org>; Tue, 20 Dec 2005 10:45:25 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by 82-171-132-56.dsl.ip.tiscali.nl (Postfix) with ESMTP id 47368C01A0
for <48038@bugs.debian.org>; Tue, 20 Dec 2005 10:45:25 +0100 (CET)
Message-ID: <43A7D2B4.2070803@yahoo.co.uk>
Date: Tue, 20 Dec 2005 10:45:24 +0100
From: Thomas Hood
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: 48038@bugs.debian.org
References: <43A75332.8090406@yahoo.co.uk> <20051220010911.GA25361@furryterror.org>
In-Reply-To: <20051220010911.GA25361@furryterror.org>
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at tudelft.nl
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Zygo Blaxell originally wrote in Oct 1999:
> mv attempts to move directories when rename() fails. This causes code
> which relied on the old behavior to determine whether files existed on the
> same filesystem to fail in horrible ways.
>
> There should either be an option to request this new behavior, or an
> option to disable it.
Zygo Blaxell recently wrote:
[...]
> There's two cases of note: one where the source is a directory (so
> mv copies the directory and attempts to remove the original), and one
> where the source is a file but the file is in an unwritable directory
> (so mv copies this file as in the directory case). The latter case is
> especially annoying since the removal of the original file always fails,
> leaving me with two copies to clean up. The latter case occurs quite
> often for me when trying to 'mv' a file owned by another user from /tmp to
> somewhere else--the old 'mv' would have given up after the rename() system
> call fails, the new 'mv' acts like 'cp' but with more error messages.
>
> The behavior seems to be mandated by some standards organization--everybody's
> mv seems to have this annoying behavior now, not just GNU's. :-(
Jim Meyering: Is this correct?
> If 'mv' *must* have this behavior, it would be preferable if it tried
> these in order:
>
> 1. rename(filea, fileb). If successful exit.
>
> 2. link(filea, fileb) followed by unlink(filea). If successful exit.
>
> 3. if and only if the error from the link was "invalid
> cross-device link", copy (filea, fileb) followed by unlink(filea)
> (possibly using recursive directory-copying code as mv does now).
> If successful exit.
>
> 4. Exit with an error.
>
> I would prefer to have an option for a "no-copy mode", where mv does
> everything it does now, except that it gives up if it is forced to try
> to copy anything.
--
Thomas Hood
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Michael Stone <mstone@debian.org>.
-t
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Thomas Hood
Subject: Bug#48038: Info received (was Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails")
Message-ID:
In-Reply-To: <43A7D2B4.2070803@yahoo.co.uk>
References: <43A7D2B4.2070803@yahoo.co.uk>
Precedence: bulk
X-Debian-PR-Message: ack-info 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.
Your message has been sent to the package maintainer(s):
Michael Stone
If you wish to continue to submit further information on your problem,
please send it to 48038@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Received: (at 48038) by bugs.debian.org; 20 Dec 2005 09:45:58 +0000
From jdthood@yahoo.co.uk Tue Dec 20 01:45:57 2005
Return-path:
Received: from mailservice.tudelft.nl ([130.161.131.5])
by spohr.debian.org with esmtp (Exim 4.50)
id 1Eoe4D-0002SE-JQ
for 48038@bugs.debian.org; Tue, 20 Dec 2005 01:45:57 -0800
Received: from localhost (localhost [127.0.0.1])
by rav.antivirus (Postfix) with ESMTP id D291F232EF2
for <48038@bugs.debian.org>; Tue, 20 Dec 2005 10:45:25 +0100 (CET)
Received: from 82-171-132-56.dsl.ip.tiscali.nl (x100.decis.nl [130.161.177.100])
by mx2.tudelft.nl (Postfix) with ESMTP id 5BEC1232EA9
for <48038@bugs.debian.org>; Tue, 20 Dec 2005 10:45:25 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by 82-171-132-56.dsl.ip.tiscali.nl (Postfix) with ESMTP id 47368C01A0
for <48038@bugs.debian.org>; Tue, 20 Dec 2005 10:45:25 +0100 (CET)
Message-ID: <43A7D2B4.2070803@yahoo.co.uk>
Date: Tue, 20 Dec 2005 10:45:24 +0100
From: Thomas Hood
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: 48038@bugs.debian.org
Subject: Re: Bug#48038: closable?: "mv: Please provide option to disable attempt
to move directories when rename() fails"
References: <43A75332.8090406@yahoo.co.uk> <20051220010911.GA25361@furryterror.org>
In-Reply-To: <20051220010911.GA25361@furryterror.org>
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at tudelft.nl
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Zygo Blaxell originally wrote in Oct 1999:
> mv attempts to move directories when rename() fails. This causes code
> which relied on the old behavior to determine whether files existed on the
> same filesystem to fail in horrible ways.
>
> There should either be an option to request this new behavior, or an
> option to disable it.
Zygo Blaxell recently wrote:
[...]
> There's two cases of note: one where the source is a directory (so
> mv copies the directory and attempts to remove the original), and one
> where the source is a file but the file is in an unwritable directory
> (so mv copies this file as in the directory case). The latter case is
> especially annoying since the removal of the original file always fails,
> leaving me with two copies to clean up. The latter case occurs quite
> often for me when trying to 'mv' a file owned by another user from /tmp to
> somewhere else--the old 'mv' would have given up after the rename() system
> call fails, the new 'mv' acts like 'cp' but with more error messages.
>
> The behavior seems to be mandated by some standards organization--everybody's
> mv seems to have this annoying behavior now, not just GNU's. :-(
Jim Meyering: Is this correct?
> If 'mv' *must* have this behavior, it would be preferable if it tried
> these in order:
>
> 1. rename(filea, fileb). If successful exit.
>
> 2. link(filea, fileb) followed by unlink(filea). If successful exit.
>
> 3. if and only if the error from the link was "invalid
> cross-device link", copy (filea, fileb) followed by unlink(filea)
> (possibly using recursive directory-copying code as mv does now).
> If successful exit.
>
> 4. Exit with an error.
>
> I would prefer to have an option for a "no-copy mode", where mv does
> everything it does now, except that it gives up if it is forced to try
> to copy anything.
--
Thomas Hood
Information forwarded to debian-bugs-dist@lists.debian.org, Michael Stone <mstone@debian.org>:
Bug#48038; Package fileutils.
debian-bugs-dist@lists.debian.orgMichael Stone
X-Loop: owner@bugs.debian.org
Subject: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Reply-To: Jim Meyering , 48038@bugs.debian.org
Resent-From: Jim Meyering
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Michael Stone
Resent-Date: Tue, 20 Dec 2005 10:48:03 UTC
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Received: via spool by 48038-submit@bugs.debian.org id=B48038.113507565718064
(code B ref 48038); Tue, 20 Dec 2005 10:48:03 UTC
Received: (at 48038) by bugs.debian.org; 20 Dec 2005 10:47:37 +0000
Received: from mx.meyering.net ([82.230.74.64])
by spohr.debian.org with esmtp (Exim 4.50)
id 1Eof1s-0004h6-Uc
for 48038@bugs.debian.org; Tue, 20 Dec 2005 02:47:37 -0800
Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000)
id 02DC3F24; Tue, 20 Dec 2005 11:47:34 +0100 (CET)
From: Jim Meyering
To: Thomas Hood
Cc: 48038@bugs.debian.org
In-Reply-To: <43A7D2B4.2070803@yahoo.co.uk> (Thomas Hood's message of "Tue, 20
Dec 2005 10:45:24 +0100")
References: <43A75332.8090406@yahoo.co.uk>
<20051220010911.GA25361@furryterror.org>
<43A7D2B4.2070803@yahoo.co.uk>
Date: Tue, 20 Dec 2005 11:47:34 +0100
Message-ID: <87irtk2gft.fsf@rho.meyering.net>
Lines: 73
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Thomas Hood wrote:
> Zygo Blaxell originally wrote in Oct 1999:
>> mv attempts to move directories when rename() fails. This causes code
>> which relied on the old behavior to determine whether files existed on the
>> same filesystem to fail in horrible ways.
>>
>> There should either be an option to request this new behavior, or an
>> option to disable it.
>
>
> Zygo Blaxell recently wrote:
> [...]
>> There's two cases of note: one where the source is a directory (so
>> mv copies the directory and attempts to remove the original), and one
>> where the source is a file but the file is in an unwritable directory
>> (so mv copies this file as in the directory case). The latter case is
>> especially annoying since the removal of the original file always fails,
>> leaving me with two copies to clean up. The latter case occurs quite
I cannot reproduce that.
Here's what I tried, as a non-root user, using mv from coreutils-5.93:
$ mv /tmp/.X0-lock /var/tmp/j
mv: cannot move `/tmp/.X0-lock' to `/var/tmp/j': Operation not permitted
[Exit 1]
$ ls -l /tmp/.X0-lock /var/tmp/j
ls: /var/tmp/j: No such file or directory
-r--r--r-- 2 root root 11 Dec 19 04:13 /tmp/.X0-lock
[Exit 2]
If you can reproduce it, please be sure to let
us know the types of file systems and (OS) involved.
Also, please run mv under strace and include its output.
>> often for me when trying to 'mv' a file owned by another user from /tmp to
>> somewhere else--the old 'mv' would have given up after the rename() system
>> call fails, the new 'mv' acts like 'cp' but with more error messages.
>>
>> The behavior seems to be mandated by some standards organization--everybody's
>> mv seems to have this annoying behavior now, not just GNU's. :-(
>
> Jim Meyering: Is this correct?
It is true that if rename fails, mv must copy then remove --
which means we lose atomicity.
>> If 'mv' *must* have this behavior, it would be preferable if it tried
>> these in order:
>>
>> 1. rename(filea, fileb). If successful exit.
>>
>> 2. link(filea, fileb) followed by unlink(filea). If successful exit.
This would be nice, but it has a fatal flaw:
If mv is killed between the link and unlink, then
it has the unacceptable side effect of leaving the
source and dest. linked.
>> 3. if and only if the error from the link was "invalid
>> cross-device link", copy (filea, fileb) followed by unlink(filea)
>> (possibly using recursive directory-copying code as mv does now).
>> If successful exit.
>>
>> 4. Exit with an error.
>>
>> I would prefer to have an option for a "no-copy mode", where mv does
>> everything it does now, except that it gives up if it is forced to try
>> to copy anything.
That is a good idea.
I'd welcome a complete patch (ChangeLog, texinfo docs (including justification)
unified diffs, and test case(s)).
Acknowledgement sent to Jim Meyering <jim@meyering.net>:
Extra info received and forwarded to list. Copy sent to Michael Stone <mstone@debian.org>.
-t
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Jim Meyering
Subject: Bug#48038: Info received (was Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails")
Message-ID:
In-Reply-To: <87irtk2gft.fsf@rho.meyering.net>
References: <87irtk2gft.fsf@rho.meyering.net>
Precedence: bulk
X-Debian-PR-Message: ack-info 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.
Your message has been sent to the package maintainer(s):
Michael Stone
If you wish to continue to submit further information on your problem,
please send it to 48038@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Received: (at 48038) by bugs.debian.org; 20 Dec 2005 10:47:37 +0000
From jim@meyering.net Tue Dec 20 02:47:37 2005
Return-path:
Received: from mx.meyering.net ([82.230.74.64])
by spohr.debian.org with esmtp (Exim 4.50)
id 1Eof1s-0004h6-Uc
for 48038@bugs.debian.org; Tue, 20 Dec 2005 02:47:37 -0800
Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000)
id 02DC3F24; Tue, 20 Dec 2005 11:47:34 +0100 (CET)
From: Jim Meyering
To: Thomas Hood
Cc: 48038@bugs.debian.org
Subject: Re: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
In-Reply-To: <43A7D2B4.2070803@yahoo.co.uk> (Thomas Hood's message of "Tue, 20
Dec 2005 10:45:24 +0100")
References: <43A75332.8090406@yahoo.co.uk>
<20051220010911.GA25361@furryterror.org>
<43A7D2B4.2070803@yahoo.co.uk>
Date: Tue, 20 Dec 2005 11:47:34 +0100
Message-ID: <87irtk2gft.fsf@rho.meyering.net>
Lines: 73
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Thomas Hood wrote:
> Zygo Blaxell originally wrote in Oct 1999:
>> mv attempts to move directories when rename() fails. This causes code
>> which relied on the old behavior to determine whether files existed on the
>> same filesystem to fail in horrible ways.
>>
>> There should either be an option to request this new behavior, or an
>> option to disable it.
>
>
> Zygo Blaxell recently wrote:
> [...]
>> There's two cases of note: one where the source is a directory (so
>> mv copies the directory and attempts to remove the original), and one
>> where the source is a file but the file is in an unwritable directory
>> (so mv copies this file as in the directory case). The latter case is
>> especially annoying since the removal of the original file always fails,
>> leaving me with two copies to clean up. The latter case occurs quite
I cannot reproduce that.
Here's what I tried, as a non-root user, using mv from coreutils-5.93:
$ mv /tmp/.X0-lock /var/tmp/j
mv: cannot move `/tmp/.X0-lock' to `/var/tmp/j': Operation not permitted
[Exit 1]
$ ls -l /tmp/.X0-lock /var/tmp/j
ls: /var/tmp/j: No such file or directory
-r--r--r-- 2 root root 11 Dec 19 04:13 /tmp/.X0-lock
[Exit 2]
If you can reproduce it, please be sure to let
us know the types of file systems and (OS) involved.
Also, please run mv under strace and include its output.
>> often for me when trying to 'mv' a file owned by another user from /tmp to
>> somewhere else--the old 'mv' would have given up after the rename() system
>> call fails, the new 'mv' acts like 'cp' but with more error messages.
>>
>> The behavior seems to be mandated by some standards organization--everybody's
>> mv seems to have this annoying behavior now, not just GNU's. :-(
>
> Jim Meyering: Is this correct?
It is true that if rename fails, mv must copy then remove --
which means we lose atomicity.
>> If 'mv' *must* have this behavior, it would be preferable if it tried
>> these in order:
>>
>> 1. rename(filea, fileb). If successful exit.
>>
>> 2. link(filea, fileb) followed by unlink(filea). If successful exit.
This would be nice, but it has a fatal flaw:
If mv is killed between the link and unlink, then
it has the unacceptable side effect of leaving the
source and dest. linked.
>> 3. if and only if the error from the link was "invalid
>> cross-device link", copy (filea, fileb) followed by unlink(filea)
>> (possibly using recursive directory-copying code as mv does now).
>> If successful exit.
>>
>> 4. Exit with an error.
>>
>> I would prefer to have an option for a "no-copy mode", where mv does
>> everything it does now, except that it gives up if it is forced to try
>> to copy anything.
That is a good idea.
I'd welcome a complete patch (ChangeLog, texinfo docs (including justification)
unified diffs, and test case(s)).
Information forwarded to debian-bugs-dist@lists.debian.org, Michael Stone <mstone@debian.org>:
Bug#48038; Package fileutils.
debian-bugs-dist@lists.debian.orgMichael Stone
X-Loop: owner@bugs.debian.org
Subject: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
Reply-To: Jim Meyering , 48038@bugs.debian.org
Resent-From: Jim Meyering
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Michael Stone
Resent-Date: Tue, 20 Dec 2005 11:18:09 UTC
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Received: via spool by 48038-submit@bugs.debian.org id=B48038.113507702115478
(code B ref 48038); Tue, 20 Dec 2005 11:18:09 UTC
Received: (at 48038) by bugs.debian.org; 20 Dec 2005 11:10:21 +0000
Received: from mx.meyering.net ([82.230.74.64])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EofNt-00041M-Km
for 48038@bugs.debian.org; Tue, 20 Dec 2005 03:10:21 -0800
Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000)
id 7BA28F24; Tue, 20 Dec 2005 12:10:20 +0100 (CET)
From: Jim Meyering
To: Thomas Hood
Cc: 48038@bugs.debian.org
In-Reply-To: <87irtk2gft.fsf@rho.meyering.net> (Jim Meyering's message of
"Tue, 20 Dec 2005 11:47:34 +0100")
References: <43A75332.8090406@yahoo.co.uk>
<20051220010911.GA25361@furryterror.org>
<43A7D2B4.2070803@yahoo.co.uk> <87irtk2gft.fsf@rho.meyering.net>
Date: Tue, 20 Dec 2005 12:10:20 +0100
Message-ID: <87d5js2fdv.fsf@rho.meyering.net>
Lines: 33
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
I wrote:
>> Zygo Blaxell recently wrote:
>> [...]
>>> There's two cases of note: one where the source is a directory (so
>>> mv copies the directory and attempts to remove the original), and one
>>> where the source is a file but the file is in an unwritable directory
>>> (so mv copies this file as in the directory case). The latter case is
>>> especially annoying since the removal of the original file always fails,
>>> leaving me with two copies to clean up. The latter case occurs quite
>
> I cannot reproduce that.
> Here's what I tried, as a non-root user, using mv from coreutils-5.93:
>
> $ mv /tmp/.X0-lock /var/tmp/j
> mv: cannot move `/tmp/.X0-lock' to `/var/tmp/j': Operation not permitted
> [Exit 1]
> $ ls -l /tmp/.X0-lock /var/tmp/j
> ls: /var/tmp/j: No such file or directory
> -r--r--r-- 2 root root 11 Dec 19 04:13 /tmp/.X0-lock
> [Exit 2]
>
> If you can reproduce it, please be sure to let
> us know the types of file systems and (OS) involved.
> Also, please run mv under strace and include its output.
Actually, I *can* reproduce it, of course.
The above system didn't have separate partitions
for /tmp and /var. If they're separate, you do end
up with a copy in both source and destination.
One could make an argument for removing the destination
in this case, but I think that would be a little too
surprising.
Acknowledgement sent to Jim Meyering <jim@meyering.net>:
Extra info received and forwarded to list. Copy sent to Michael Stone <mstone@debian.org>.
-t
X-Loop: owner@bugs.debian.org
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Jim Meyering
Subject: Bug#48038: Info received (was Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails")
Message-ID:
In-Reply-To: <87d5js2fdv.fsf@rho.meyering.net>
References: <87d5js2fdv.fsf@rho.meyering.net>
Precedence: bulk
X-Debian-PR-Message: ack-info 48038
X-Debian-PR-Package: fileutils
X-Debian-PR-Keywords:
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.
Your message has been sent to the package maintainer(s):
Michael Stone
If you wish to continue to submit further information on your problem,
please send it to 48038@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Received: (at 48038) by bugs.debian.org; 20 Dec 2005 11:10:21 +0000
From jim@meyering.net Tue Dec 20 03:10:21 2005
Return-path:
Received: from mx.meyering.net ([82.230.74.64])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EofNt-00041M-Km
for 48038@bugs.debian.org; Tue, 20 Dec 2005 03:10:21 -0800
Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000)
id 7BA28F24; Tue, 20 Dec 2005 12:10:20 +0100 (CET)
From: Jim Meyering
To: Thomas Hood
Cc: 48038@bugs.debian.org
Subject: Re: Bug#48038: closable?: "mv: Please provide option to disable attempt to move directories when rename() fails"
In-Reply-To: <87irtk2gft.fsf@rho.meyering.net> (Jim Meyering's message of
"Tue, 20 Dec 2005 11:47:34 +0100")
References: <43A75332.8090406@yahoo.co.uk>
<20051220010911.GA25361@furryterror.org>
<43A7D2B4.2070803@yahoo.co.uk> <87irtk2gft.fsf@rho.meyering.net>
Date: Tue, 20 Dec 2005 12:10:20 +0100
Message-ID: <87d5js2fdv.fsf@rho.meyering.net>
Lines: 33
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
I wrote:
>> Zygo Blaxell recently wrote:
>> [...]
>>> There's two cases of note: one where the source is a directory (so
>>> mv copies the directory and attempts to remove the original), and one
>>> where the source is a file but the file is in an unwritable directory
>>> (so mv copies this file as in the directory case). The latter case is
>>> especially annoying since the removal of the original file always fails,
>>> leaving me with two copies to clean up. The latter case occurs quite
>
> I cannot reproduce that.
> Here's what I tried, as a non-root user, using mv from coreutils-5.93:
>
> $ mv /tmp/.X0-lock /var/tmp/j
> mv: cannot move `/tmp/.X0-lock' to `/var/tmp/j': Operation not permitted
> [Exit 1]
> $ ls -l /tmp/.X0-lock /var/tmp/j
> ls: /var/tmp/j: No such file or directory
> -r--r--r-- 2 root root 11 Dec 19 04:13 /tmp/.X0-lock
> [Exit 2]
>
> If you can reproduce it, please be sure to let
> us know the types of file systems and (OS) involved.
> Also, please run mv under strace and include its output.
Actually, I *can* reproduce it, of course.
The above system didn't have separate partitions
for /tmp and /var. If they're separate, you do end
up with a copy in both source and destination.
One could make an argument for removing the destination
in this case, but I think that would be a little too
surprising.
Tags added: upstream
Request was from Thomas Hood <jdthood@yahoo.co.uk>
to control@bugs.debian.org.
Received: (at control) by bugs.debian.org; 1 Jan 2006 01:05:09 +0000
From jdthood@yahoo.co.uk Sat Dec 31 17:05:09 2005
Return-path:
Received: from smtp-out3.tiscali.nl ([195.241.79.178])
by spohr.debian.org with esmtp (Exim 4.50)
id 1Esrem-0003Ew-St
for control@bugs.debian.org; Sat, 31 Dec 2005 17:05:09 -0800
Received: from [82.171.132.56] (helo=82-171-132-56.dsl.ip.tiscali.nl)
by smtp-out3.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl)
id 1Esrem-0008Ce-4m
for ; Sun, 01 Jan 2006 02:05:08 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
by 82-171-132-56.dsl.ip.tiscali.nl (Postfix) with ESMTP id 42B20BFEFE
for ; Sun, 1 Jan 2006 03:05:10 +0100 (CET)
Message-ID: <43B738D5.3080803@yahoo.co.uk>
Date: Sun, 01 Jan 2006 03:05:09 +0100
From: Thomas Hood
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: control@bugs.debian.org
Subject: tags, etc.
X-Enigmail-Version: 0.92.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Delivered-To: control@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,VALID_BTS_CONTROL
autolearn=no version=2.60-bugs.debian.org_2005_01_02
tags 68603 wontfix
tags 185152 wontfix
tags 17025 wontfix
retitle 120650 coreutils: chmod: Please add R, W, S and T options
retitle 210475 coreutils: stty: Please add option to force stty to act immediately, not to wait for output to be empty
retitle 21750 coreutils: install: Please add option to compress files
tags 21750 wontfix
tags 48038 upstream
retitle 55218 coreutils: ls: Please add option to sort by type (i.e., all directories before all files)
tags 56844 wontfix
tags 89335 wontfix
stop