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.har...@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" <ebl...@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
