GNU bug report logs - #30907
mv return value.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30907 in the body.
You can then email your comments to 30907 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: mv return value.
Date: Thu, 22 Mar 2018 17:02:59 +0000

[Message part 1 (text/plain, inline)]

The documentation specifies the usual exit convention, but doesn’t say what counts as success. For example, I would like
       mv -i a b || (diff a b && rm a)
to rename a if b does not exist and to remove a if they are identical, but it doesn’t work.

Regards,
Jorgen Harmse

Sam’s Club Technology
Phone 512.633.2226
jorgen.harmse <at> samsclub.com


This e-mail and any files transmitted with it are confidential and intended solely
for the individual or entity to whom they are addressed.  If you have received
this e-mail in error, destroy it immediately.  Wal-Mart Confidential.

[Message part 2 (text/html, inline)]

Message #8 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>, 30907 <at> debbugs.gnu.org
Subject: Re: bug#30907: mv return value.
Date: Thu, 22 Mar 2018 11:48:32 -0700

On 03/22/2018 10:02 AM, Jorgen Harmse wrote:
> The documentation specifies the usual exit convention, but doesn’t say what counts as success. For example, I would like
>         mv -i a b || (diff a b && rm a)
> to rename a if b does not exist and to remove a if they are identical, but it doesn’t work.

I'm afraid that's a bit vague. What wording change do you suggest?

Message #11 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
Cc: 30907 <at> debbugs.gnu.org
Subject: Re: bug#30907: mv return value.
Date: Thu, 22 Mar 2018 14:53:51 -0700

On 03/22/2018 12:17 PM, Jorgen Harmse wrote:
> My preference is a non-zero exit status when mv does not move/rename the file.

Hmm, this might be doable. POSIX says that the mv exit status is 0 if 
"All input files were moved successfully" and is >0 if "An error 
occurred". With mv -i, if the user declines a move and there is other 
file then neither case applies, so mv can yield either 0 or nonzero as 
an exit status. Of course someone would have to write the code and (more 
importantly) the documentation to do it that way, but I think your 
request is a reasonable one.

Message #14 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>,
 Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
Cc: 30907 <at> debbugs.gnu.org
Subject: Re: bug#30907: mv return value.
Date: Thu, 22 Mar 2018 17:00:25 -0500

On 03/22/2018 04:53 PM, Paul Eggert wrote:
> On 03/22/2018 12:17 PM, Jorgen Harmse wrote:
>> My preference is a non-zero exit status when mv does not move/rename 
>> the file.
> 
> Hmm, this might be doable. POSIX says that the mv exit status is 0 if 
> "All input files were moved successfully" and is >0 if "An error 
> occurred". With mv -i, if the user declines a move and there is other 
> file then neither case applies, so mv can yield either 0 or nonzero as 
> an exit status. Of course someone would have to write the code and (more 
> importantly) the documentation to do it that way, but I think your 
> request is a reasonable one.

I'd argue the opposite: 0 implies success ("I successfully moved all 0 
files that you interactively approved for me to move"), while 1 implies 
failure ("I failed to move a file, AND printed an error message why"). 
When the user declines to move a file, we don't print an error message, 
so that should NOT be treated as an error, but successfully skipping the 
file.  We didn't fail to move the file, because we didn't even attempt 
to move the file.  That is, interactive decisions can only reduce the 
set of files to attempt to move, and not be treated as errors on t heir own.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Message #17 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
To: Eric Blake <eblake <at> redhat.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "30907 <at> debbugs.gnu.org" <30907 <at> debbugs.gnu.org>
Subject: Re: bug#30907: mv return value.
Date: Thu, 22 Mar 2018 22:47:32 +0000

I see Eric's point, but it seems to me that my use case is not unusual. (Rename a file unless the target exists, in which case check that they are the same before removing one.) Perhaps the documentation of mv could suggest a solution, e.g.

(ls b &> /dev/null && diff a b > /dev/null && rm a) || mv -n a b

Regards,
Jorgen Harmse
 
Sam’s Club Technology
Phone 512.633.2226 
jorgen.harmse <at> samsclub.com
 
 
This e-mail and any files transmitted with it are confidential and intended solely
for the individual or entity to whom they are addressed.  If you have received
this e-mail in error, destroy it immediately.  Wal-Mart Confidential.
 
On 3/22/18, 17:01, "Eric Blake" <eblake <at> redhat.com> wrote:

    On 03/22/2018 04:53 PM, Paul Eggert wrote:
    > On 03/22/2018 12:17 PM, Jorgen Harmse wrote:
    >> My preference is a non-zero exit status when mv does not move/rename 
    >> the file.
    > 
    > Hmm, this might be doable. POSIX says that the mv exit status is 0 if 
    > "All input files were moved successfully" and is >0 if "An error 
    > occurred". With mv -i, if the user declines a move and there is other 
    > file then neither case applies, so mv can yield either 0 or nonzero as 
    > an exit status. Of course someone would have to write the code and (more 
    > importantly) the documentation to do it that way, but I think your 
    > request is a reasonable one.
    
    I'd argue the opposite: 0 implies success ("I successfully moved all 0 
    files that you interactively approved for me to move"), while 1 implies 
    failure ("I failed to move a file, AND printed an error message why"). 
    When the user declines to move a file, we don't print an error message, 
    so that should NOT be treated as an error, but successfully skipping the 
    file.  We didn't fail to move the file, because we didn't even attempt 
    to move the file.  That is, interactive decisions can only reduce the 
    set of files to attempt to move, and not be treated as errors on t heir own.
    
    -- 
    Eric Blake, Principal Software Engineer
    Red Hat, Inc.           +1-919-301-3266
    Virtualization:  qemu.org | libvirt.org
    
    

Message #20 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "30907 <at> debbugs.gnu.org" <30907 <at> debbugs.gnu.org>
Subject: Re: bug#30907: mv return value.
Date: Fri, 23 Mar 2018 08:00:01 -0500

On 03/22/2018 05:47 PM, Jorgen Harmse wrote:
> I see Eric's point, but it seems to me that my use case is not unusual. (Rename a file unless the target exists, in which case check that they are the same before removing one.) Perhaps the documentation of mv could suggest a solution, e.g.
> 
> (ls b &> /dev/null && diff a b > /dev/null && rm a) || mv -n a b

That's a TOCTTOU race.

It sounds like what you want is close to the kernel's 
renameat2(,RENAME_NOREPLACE) semantics, which atomically renames a file 
or fails if the destination already exists, then on failure check if the 
two files are identical before removing the source.

I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should 
be taught to do so, where such semantics are available.

> This e-mail and any files transmitted with it are confidential and intended solely

This disclaimer is unenforceable on publicly archived mailing lists. 
You may want to send from a personal account instead of spamming us with 
your employer's legalese when posting to open source lists.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Message #23 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
To: Eric Blake <eblake <at> redhat.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "30907 <at> debbugs.gnu.org" <30907 <at> debbugs.gnu.org>
Subject: Re: bug#30907: mv return value.
Date: Fri, 23 Mar 2018 13:41:10 +0000

renameat2 looks like what I need. (The TOCTTOU problem did not apply to my most recent use case (and would have been annoying rather than severe), but I see your point.) Given your objection to having mv -i fail in my case, I guess exposing those semantics means adding to the interface:

--interactive-fail
  like --interactive, but return non-zero status if the user chooses not to overwrite a file

--no-clobber-fail
  like --no-clobber, but return non-zero status if the target exists

Regards,
Jorgen Harmse
 
Sam’s Club Technology
Phone 512.633.2226 
jorgen.harmse <at> samsclub.com
 
 
This e-mail and any files transmitted with it are confidential and intended solely
for the individual or entity to whom they are addressed.  If you have received
this e-mail in error, destroy it immediately.  Wal-Mart Confidential.
 
On 3/23/18, 08:00, "Eric Blake" <eblake <at> redhat.com> wrote:

    On 03/22/2018 05:47 PM, Jorgen Harmse wrote:
    > I see Eric's point, but it seems to me that my use case is not unusual. (Rename a file unless the target exists, in which case check that they are the same before removing one.) Perhaps the documentation of mv could suggest a solution, e.g.
    > 
    > (ls b &> /dev/null && diff a b > /dev/null && rm a) || mv -n a b
    
    That's a TOCTTOU race.
    
    It sounds like what you want is close to the kernel's 
    renameat2(,RENAME_NOREPLACE) semantics, which atomically renames a file 
    or fails if the destination already exists, then on failure check if the 
    two files are identical before removing the source.
    
    I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should 
    be taught to do so, where such semantics are available.
    
    > This e-mail and any files transmitted with it are confidential and intended solely
    
    This disclaimer is unenforceable on publicly archived mailing lists. 
    You may want to send from a personal account instead of spamming us with 
    your employer's legalese when posting to open source lists.
    
    -- 
    Eric Blake, Principal Software Engineer
    Red Hat, Inc.           +1-919-301-3266
    Virtualization:  qemu.org | libvirt.org
    
    

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: "30907 <at> debbugs.gnu.org" <30907 <at> debbugs.gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>, bug-coreutils <at> gnu.org,
 Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
Subject: Re: bug#30907: mv return value.
Date: Fri, 23 Mar 2018 14:45:50 +0100

On Friday, March 23, 2018 2:00:01 PM CET Eric Blake wrote:
> I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should
> be taught to do so, where such semantics are available.

mv was recently patched to use renameat2(..., RENAME_NOREPLACE):

http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.29-9-g29baf25aa

Kamil

Message #32 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
To: Kamil Dudka <kdudka <at> redhat.com>, Eric Blake <eblake <at> redhat.com>
Cc: "30907 <at> debbugs.gnu.org" <30907 <at> debbugs.gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>,
 "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: Re: bug#30907: mv return value.
Date: Fri, 23 Mar 2018 14:14:39 +0000

Thank you. I don't see renameat2 on my system, but this should be good for systems that have it.

Regards,
Jorgen Harmse
 
Sam’s Club Technology
Phone 512.633.2226 
jorgen.harmse <at> samsclub.com
 
 
On 3/23/18, 08:55, "Kamil Dudka" <kdudka <at> redhat.com> wrote:

    On Friday, March 23, 2018 2:00:01 PM CET Eric Blake wrote:
    > I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should
    > be taught to do so, where such semantics are available.
    
    mv was recently patched to use renameat2(..., RENAME_NOREPLACE):
    
    http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.29-9-g29baf25aa
    
    Kamil
    

Message #38 received at 30907 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 30907 <at> debbugs.gnu.org
Subject: Re: bug#30907: mv return value.
Date: Mon, 29 Oct 2018 20:57:11 -0600

tags 30907 fixed
close 30907
stop

(triaging old bugs)

On 2018-03-23 7:45 a.m., Kamil Dudka wrote:
> On Friday, March 23, 2018 2:00:01 PM CET Eric Blake wrote:
>> I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should
>> be taught to do so, where such semantics are available.
> 
> mv was recently patched to use renameat2(..., RENAME_NOREPLACE):
> 
> http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.29-9-g29baf25aa

Give the above, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.