bug#30907: mv return value.

[Jorgen Harmse]

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 
address@hidden
 
 
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" <address@hidden> 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