Hide Forgot
Ends in a number of errors: mv: will not overwrite just-created [file] with [file]. I haven't had the time to debug this completely; it might be a bug in the new cp, but I believe it's caused by another intentional (POSIX-compliance induced) madness.
And what issue would that be?
Loads of mv: will not overwrite just-created [file] with [file]. errors during make install (basically one for every file). Try upgrading fileutils to the version in the rawhide tree and rebuilding mx to see for yourself. Might still be a fileutils issue; I'll debug this once the S390 stuff is done, unless you beat me to it.
I was thinking of what the POSIX compliance issue would be... I've never seen Posix demand "don't do what the user say" before.
Suspicious items from the changelog: * mv now prompts before overwriting an existing, unwritable destination file when stdin is a tty, unless --force (-f) is specified, as per POSIX. [doesn't state what it does when stdin isn't a tty] * cp's -P option now means the same as --no-dereference, per POSIX. Use --parents to get the old meaning.
Is stdin really a tty when using rpm to build a package?
rpm does not change stdin, only dup's fd #0 for running scripts. So stdin is whatever it is/was when rpm is/was invoked.
The error seems genuine; just looked through the cp code causing the message: /* Don't let the user destroy their data, even if they try hard: This mv command must fail (likewise for cp): rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c Otherwise, the contents of b/f would be lost. In the case of `cp', b/f would be lost if the user simulated a move using cp and rm. Note that it works fine if you use --backup=numbered. */ if (command_line_arg && x->backup_type != numbered && seen_dest (dst_path, dst_sb)) { error (0, 0, _("will not overwrite just-created %s with %s"), quote_n (0, dst_path), quote_n (1, src_path)); return 1; }
So this is a fileutils bug? It certainly looks like one...
Reassigning component.
Fixed in 4.1.2-2.