Repository navigation
feat: add --rename flag to auto-rename on conflict - #1088
GhostCoder6969 wants to merge 4 commits into
Conversation
Adds a global --rename flag that resolves file conflicts by renaming without prompting, instead of answering them with --yes/--no or typing r each time. Closes ouch-org#901.
|
This command now crashes ouch: With the --here option, --rename does not handle all conflicts. It throws an error when a symlink, hard link or folder in the archive has the same name as an existing file or a file has the same name as an existing folder --rename also says yes to the other questions ouch asks, not only to conflicts |
--rename plus --yes errored out cleanly instead of panicking, other questions ask again instead of copying --yes, and symlink, hardlink and dir entries rename aside on conflict.
|
Good catches, all three are fixed now. The --rename plus --yes crash was real, my bad. Clap only caught that clash when both flags came before the subcommand, so it slipped through and hit an unreachable. It errors out cleanly now. --rename no longer says yes to the other questions, that was wrong of me. It only covers file conflicts and everything else asks like normal. And the --here clashes work now. Symlinks, hardlinks and files landing on each other rename aside, and when a directory lands on an existing file the file moves aside so the archive layout stays intact. I tried each case by hand plus three new tests, full suite green. |
|
There are a few more issues left:
|
…rs aside --yes plus --no without --rename no longer reports the rename error, it gets its own message now. The rename error only fires when --rename is actually passed. Non-conflict questions (unknown extension and the like) still prompt under --rename, covered by tests answering yes and no. A tar or zip directory landing on an existing file renames the incoming entry aside now, the user's file stays untouched, and entries below the renamed directory follow it. Matches the --rename help text.
|
All four fixed, I think thats all four. The fmt failure was just my import wrapping in zip.rs, I ran cargo fmt and it is clean now. The --yes plus --no thing was my catch all arm firing the rename error even when --rename was never passed. I split the checks so the rename error only fires when --rename is actually there, and --yes with --no gets its own message now. The unknown extension question already asks again after my last push, I checked it by hand piping y and n in. I added two tests so it stays that way, one answers yes and extracts, the other answers no and nothing gets written. The tar folder case was backwards, you were right. I moved the user file aside before and now the incoming directory goes to x_1 instead, with everything below it following along. Zip got the same treatment since it errored out there. This matches the flag help text too, it says the output gets renamed. Full suite green on my end plus the fmt check. |
A 7z directory landing on an existing file errored out instead of renaming aside like tar and zip do. 7z lists files before their parent dirs, so entries below a blocked path move the topmost blocking ancestor aside first and follow it. Covered by a test mirroring the tar and zip cases.
|
I went through every item again on the current branch. The fmt check is clean, the yes plus no clash gets its own error now, the format sniffing question still asks under rename, tar puts the incoming folder aside and keeps your file, and the rename plus yes combos error out cleanly in every flag order. The one real gap I found was 7z, a folder landing on a file errored out there, so I gave it the same treatment as tar and zip and added a test for it. Full suite is green on my end. |
|
2 participants
Closes #901. There is now a global --rename flag that answers every file conflict with the rename option, so scripts stop prompting for input. It conflicts with --yes and --no, and the --help snapshots are updated. I verified the flag end to end with a new integration test plus the full suite with --no-default-features (this box has no libclang for the default build, CI will cover that). Happy to rename the flag if you prefer something else.