Bug Report: Renaming Options - Prevent Duplicates

[spacev2]

I am experiencing a bug in regards to the "Renaming Options - Prevent Duplicates".

Sometimes when renaming files with the "Prevent duplicates" feature enabled it will add an additional "_1" suffix onto the file names.

Here is a picture demonstrating the issue:

[spacev2]

Just to clarify, I am currently using Bulk Rename Utility v4.0.0.0 BETA. But this issue has been present in previous versions also.

[Admin]

Hi, thanks for the report. I am not able to reproduce this issue....
What renaming criteria are you using? thanks

[spacev2]

It does not happen all the time, but it does happen.

The naming criteria I use when this issue occurs is as follows:

- Renaming Options / Prevent Duplicates... (Enabled)
- Remove (5) "Last n"

Nothing complex, just removing part of the end of the files name.

One additional piece of information is that when this issue does occur, I am able to reproduce it by going to "Actions / Undo Rename" and then applying the renaming criteria on the same files again will output the exact same result.

[Admin]

Thanks, how many files are you renerenaming when this happens? Are you renaming across folders?
It sounds like the deduplication detected that ButtonBeep_1, ButtonBeep_2, ButtonBeep_3 and ButtonBeep_4 already existed and so it added an extra _1.
Do these files exist on disk and are maybe filtered out?

[spacev2]

Typically my duplicate files only range between 1 - 20 more or less.

I just double checked my disk and you were correct. The files name did already exist on the disk inside of the same folder.



However I am a little confused because I did not have any filters applied and BRU was only showing 8x "ButtonBeep_HV.XXX" files as shown in the original post. I honestly don't know what exactly happened wit the other 4x ButtonBeep files but I will just consider it as user error at this point. However I am certain that this issue has happened before because I clearly remember removing the extra "_1" suffix on the files names and it did not conflict with anything.

I will update this thread if I run into this issue again.

Thanks

[Admin]

Maybe there were some renaming performed and it was stopped or there were some renaming errors? Mayne the list was not refreshed.

[spacev2]

I can only speculate from this point onwards. I will try to do some more thorough investigating if I run into this issue again in the future.

Thanks for the help.

[therube]

What happens if you take the same set of files, & set the 'Rename in Reverse Order' option (along with the Prevent Duplicates)?

Oops, never mind.
(I should have finished reading the thread before I started to post .)

[spacev2]

I just ran into this bug again but under different circumstances.

In the past, I only noticed this happening when I would remove part of a file name which would result in multiple files having the same name and then I was relying on the "prevent duplicates" functionality to number them automatically (instead of manually inserting numbers in to the file names).


However, this time was slightly different circumstances:

The original file names were:

Hit_Hard_Sting_v1
Hit_Hard_Sting_v2

I was removing the "v" in front of the numbers using the following renaming criteria:

Replace (3)
Replace: v1|v2|v3|v4|v5|v6|v7|v8|v9
With: 1|2|3|4|5|6|7|8|9


For unknown reasons, BRU thought there was a duplicate file name for:
Hit_Hard_Sting_1
Hit_Hard_Sting_2

and outputted the following:
Hit_Hard_Sting_1_1
Hit_Hard_Sting_1_2


For unknown reasons, BRU inserted _1 on to the end of these 2 file names.


I confirmed that there was no duplicate file names inside of the folder, as demonstrated in the picture:

[spacev2]

Edit: (I made a typo mistake)

I was supposed to say:

and outputted the following:
Hit_Hard_Sting_1_1
Hit_Hard_Sting_2_1