[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30907: mv return value.

From: Jorgen Harmse
Subject: 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:

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

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

Jorgen Harmse
Sam’s Club Technology
Phone 512.633.2226 
This e-mail and any files transmitted with it are confidential and intended 
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]