XYplorer Beta Club

I have a script that needs to rename a file, and can use either Rename or RenameItem. However, it seems that neither one can silently force an overwrite if there is a collision. That's surprising, so maybe I'm missing something.

But if not... please add an option to Rename or RenameItem (or both) to force overwrite w/o prompt.

Thanks

Trying to give an item the name of an existing one is (at least) dangerous. Just delete it (or better: copy it to a save place before) before you give a different item the old name.

Rename doesn't seem more dangerous than CopyTo or MoveTo, which can force an overwrite. Just as with those commands it's a matter of convenience - if I can force an overwrite I don't have to check for existence of the unwanted file and delete it. Things can go wrong scripting those steps too (at least in my hands ). 'Overwrite' is a reasonable switch to have on this particular command; if it was already there nobody would object. I suggest it as consistent and occasionally useful improvement.

Entirely reasonable. +1.

Corrrect me if I am wrong - couldn't this trigger an endless loop? Depending on your pattern, you overwrite, then a little later your pattern enforces the same name yet again, and yet again .....

usually it wouldn't be technically endless. Because batch renames do not operate on infinite files usually.

Unless you're renaming a.file to a.copy to a.file to a.copy to a.file to a.copy ...

Stef123 wrote:Corrrect me if I am wrong - couldn't this trigger an endless loop? Depending on your pattern, you overwrite, then a little later your pattern enforces the same name yet again, and yet again .....

No, the system would only perform one rename. It does that now, but you have to answer two confirmation prompts. Today I've answered many sets of those with more to go. I want a flag that will let me skip the confirmation, that's all.

Thanks for filling me in. I had confused things with sequential renames in another tool, where I once received warnings about an endless loop I was about to produce. So anyway, with this out of the way, I also don't see any reasons why XY should not allow the enforcement.
+1

Too dangerous.

The point is that nobody *thinks* of renaming as potentially destroying another file. This is the difference to CopyTo and MoveTo.

admin wrote:Too dangerous.

The point is that nobody *thinks* of renaming as potentially destroying another file. This is the difference to CopyTo and MoveTo.

In general I understand this.

But: if for a command the user explicitely requests this, he seems to verify that he thinks of the risc?

I was not aware that this was about scripting. OK, added it to SC renameitem.

Thank you! I'll be using it as soon as it appears.