PICARD-2496: Add option to skip moving files if destination already exists

[iron-prog]

Summary

This PR introduces a new option allowing Picard to skip moving files if the destination file already exists.

New option:
"Skip moving files if destination already exists"

Location:
Options → File Naming → Move files when saving

Behavior priority:

1. Skip move if destination exists (new option)
2. Overwrite existing files
3. Rename with (1), (2) suffix

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other
• Describe this change in 1-2 sentences:
  Adds a new configuration option allowing Picard to skip moving files if a file with the same name already exists in the destination directory.

Problem

When moving files during tagging, Picard currently either renames the file by adding a numbered suffix (e.g., (1)) or overwrites the existing file depending on user settings.
Some users prefer to leave the file untouched if a file with the same name already exists in the destination directory.

• JIRA ticket (optional): PICARD-2496

Solution

This PR introduces a new setting move_skip_existing_files.

If enabled, Picard checks whether the destination file already exists before moving a file.
If it does exist, the move operation is skipped and the file remains in its original location.

Implementation details:

• Added a new BoolOption (move_skip_existing_files) in options.py
• Updated the file renaming logic in picard/file.py to skip the move when the option is enabled
• Added a checkbox to the File Naming → Move files when saving options page
• Ensured mutual exclusivity with the existing Overwrite existing files option to avoid conflicting behavior

Default behavior remains unchanged if the option is disabled.

AI Usage

In accordance with the AI use policy portion of the MetaBrainz Contribution Guidelines, the level of AI/LLM use in the development of this Pull Request is:

• No AI/LLM use
• Minimal use (e.g. autocompletion)
• Moderate use (e.g. suggestions regarding code fragments)
• Significant use (e.g. code structure, tests development, etc.)
• Primarily AI developed
• Other (please specify below)

Action

Additional actions required:

• Update Picard documentation (please include a reference to this PR)
• Other (please specify below)

[rdswift]

I haven't reviewed this in great depth to try to understand whether it is actually necessary or if this is the best solution. If it is necessary and appropriate, the documentation will absolutely need to be updated to explain the new configuration setting, but I see that you have indicated that there are no documentation changes required.

I may be wrong, but I suspect that the AI Usage in developing this PR is actually higher than you indicated.

[rdswift]

For clarity for the users, perhaps there could be (mutually exclusive) radio buttons for the three options:

• Do not move duplicate files
• Move and rename file with numeric suffix
• Move and overwrite existing files

That way the preference could be stored in a single setting, rather than multiple binary settings relying on code to maintain their mutual exclusivity.

[iron-prog]

thanks for this suggestion it's my bad for relying on ai

[rdswift]

thanks for this suggestion it's my bad for relying on ai

This was a suggestion only, based on my initial cursory review. Others may have different opinions and different suggested preferences. I would wait until at least @phw and @zas have had a chance to comment before making any changes.

[zas]

For clarity for the users, perhaps there could be (mutually exclusive) radio buttons for the three options:

* Do not move duplicate files

* Move and rename file with numeric suffix

* Move and overwrite existing files

That way the preference could be stored in a single setting, rather than multiple binary settings relying on code to maintain their mutual exclusivity.

Yes, I think it would be clearer.
Also we need to have same thing for additional files for consistency (I think).
Also we have warning dialogs: perhaps they should clearly state what is going to happen (move where? rename how?)

[rdswift]

@zas / @phw would it make sense to define the choices in an Enum or IntEnum class rather than storing / retrieving / comparing a string value?

[rdswift]

This will get "rename" as the value if there is no 'move_conflict_strategy' setting, but will actually process as "overwrite" if there is a value other than "skip", "rename" or "overwrite".

Also, this code is repeated below in the _apply_additional_file_moves() method below. You might want to consider making this a separate helper method called from the other methods.

[iron-prog]

@rdswift Thanks for the detailed review!
I’ve made the changes as your suggestion:
• Refactored duplicate conflict-handling logic into a helper method
• Added validation and fallback handling for unexpected strategy values
• Updated the UI logic to ensure a default option is always selected
• Cleaned up related code paths for consistency

[rdswift]

Please provide meaningful descriptions for your commits. The commit message "ruff fail" on everything does not provide any useful information as to what reviewers can expect to see when they review the commit.

Also, please don't continually force push each time. That destroys the revision history for the PR and causes the reviewers to have to go through all of the changes each time, rather than what has changed incrementally since their last review (causing much more work for the reviewers and making them less likely to review and accept the PR).

I suggest that you review the following best practices and consider incorporating them into your workflow:

• https://www.w3schools.com/git/git_best_practices.asp
• https://www.ojambo.com/git-best-practices-commit-often-commit-early

[iron-prog]

there is some problem going on authentication in GitHub in my terminal like I have one previous git account which I deleted and second which I m working right now but some times it's just does not give access(or switch randomly although no sign it is in my terminal or workflow) due to which I have to force push after many changes I have tried many ways to fix it because of this I use force push and for commit message I use what I changes but sometimes in hurry or simple failure I message this

[rdswift]

In that case, I suggest that you get this sorted out and working properly before continuing to make any PR submissions. I plan to avoid any further reviews until this has been addressed.

[iron-prog]

Thanks for pointing this out, and apologies for the workflow issues.
Going forward, I’ll use incremental commits with clear messages to make review easier.

[rdswift]

Please DO NOT keep using the same commit message for everything. The commit message should indicate what has changed in that commit.

Also, you requested my review again, but you still haven't addressed all of my previous comments.

[iron-prog]

Thanks for the review I was busy with my sem examination so it's my mistake I m going to address all concerns now with precision and as you suggested.