| Summary: | mv --reply not working properly | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Voltron Rex <voltron.rex> |
| Component: | [OLD] Core system | Assignee: | Martin Schlemmer (RETIRED) <azarah> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Here is the relevant sourcecode snippet (edited for readybility):
/* cp and mv treat -i and -f differently. */
if (x->move_mode) {
if ((x->interactive == I_ALWAYS_NO
&& UNWRITABLE (dst_path, dst_sb.st_mode))
|| ((x->interactive == I_ASK_USER
|| (x->interactive == I_UNSPECIFIED
&& x->stdin_tty
&& UNWRITABLE (dst_path, dst_sb.st_mode)))
&& (overwrite_prompt (dst_path, &dst_sb), 1)
&& ! yesno ())) {
/* Pretend the rename succeeded, so the caller (mv)
doesn't end up removing the source file. */
if (rename_succeeded)
*rename_succeeded = 1;
return 0;
}
}
The condition (x->interactive == I_ALWAYS_NO && UNWRITABLE (dst_path, dst_sb.st_mode)) is the part affected by --reply=no, but only if the destination is not writable. Skipping the UNWRITABLE() test brings the desired behavior, so the question is if that's a bug or a feature (the man/info pages aren't clear on this).
closing this, as there's nothing we can really do about it |
The command 'mv --reply=no' does not work as expected. mv --help gives this information: " --reply={yes,no,query} specify how to handle the prompt about an existing destination file " I expect that this means when mv would overwrite a file it shouldn't. However, whether I use --reply=yes or --reply=no the file is always overwritten. Reproducible: Always Steps to Reproduce: 1. echo a>a; echo b>b 2. mv --reply=no a b 3. cat b Actual Results: cat b ==> 'a' Expected Results: Unless I totally misunderstand how --reply works, cat b should result in 'b' This behavior has also been confirmed on Debian unstable.