Page 2 of 3
Re: New backup name collision functionality for inline renames
Posted: 03 Dec 2010 10:51
by jjk
Yes, in this case it is a little different.
See here :
Re: New backup name collision functionality for inline renames
Posted: 03 Dec 2010 11:32
by admin
Well...

... I'm sure there are people that are happy to spend their short but valuable time on this planet with renaming options... but I would rather reduce it to the (ideally no more than 3) most useful to the average power user...
Re: New backup name collision functionality for inline renames
Posted: 03 Dec 2010 12:40
by MCS
You can get the kind of window I was talking about in windows 7 by moving a file from another folder to somewhere where a file of the same name exists. It gives you three simple choices with the last of them being keep both + suffix.
I'm also not voting for a huge rename feature that makes inline renaming a big deal. It's just that the current window "error - file already exists" is not very user friendly as the only thing you can do is press ok and manually rename stuff yourself. IMO this window would be a great and easy place to implement small, simple options that makes inline renaming faster and easier without causing any bloat.
Re: New backup name collision functionality for inline renames
Posted: 03 Dec 2010 14:07
by admin
MCS wrote:You can get the kind of window I was talking about in windows 7 by moving a file from another folder to somewhere where a file of the same name exists. It gives you three simple choices with the last of them being keep both + suffix.
I'm also not voting for a huge rename feature that makes inline renaming a big deal. It's just that the current window "error - file already exists" is not very user friendly as the only thing you can do is press ok and manually rename stuff yourself. IMO this window would be a great and easy place to implement small, simple options that makes inline renaming faster and easier without causing any bloat.
I don't think "replace" is a useful option when you rename a file. I don't think I ever intended to replace a file when renaming another file...
Re: New backup name collision functionality for normal renames
Posted: 03 Dec 2010 15:52
by admin
On second thoughts I don't think a complication of the "Cannot" interface would be an improvement. At least for me I cannot imagine a situation where I would say Yes to an automatic alternative name (let alone overwrite the existing file). But I'm open to other opinions.
Re: New backup name collision functionality for inline renames
Posted: 03 Dec 2010 17:33
by j_c_hallgren
admin wrote:I don't think "replace" is a useful option when you rename a file. I don't think I ever intended to replace a file when renaming another file...
I'll just jump in to say that I DO have that occur! And, for now, it's when I end up using "Swap Names" as substitute...the situation is: I have a file that I use as input to a VBS and the output is two files (the "Normal" lines and the "Error" lines in that file)...I then want to replace the base input with the "Normal" file...so if I could just do a rename of "LOG-NML.HTML" to "LOG.HTML" which would in effect delete the "-NML" file, that would make it a bit easier as I now do a swap and then have to delete the other file.
As far as limiting the options to 3: Is there some way that these could be picked by user via a config type setting so they could choose which ones they use most? Just a thought.
Re: New backup name collision functionality for normal renames
Posted: 03 Dec 2010 18:04
by MCS
admin wrote:On second thoughts I don't think a complication of the "Cannot" interface would be an improvement. At least for me I cannot imagine a situation where I would say Yes to an automatic alternative name (let alone overwrite the existing file). But I'm open to other opinions.
This is something I run into almost daily, although I probably do more file management than most people. It's not unusual to have files of almost identical content you want with the same file name (for me it's often sound effects files). Here's an example:
I go to the forest to record bird song and wind for a film project. I end up with 100 separate files of birdsong and wind on my portable recorder that are all named with indexed numbers only. I use the preview functionality of xyplorer to quickly listen to the files and name them according to whats in them. Filenames might be something like "Wind in trees, bright, gusty.wav" or "Birdsong, quick.wav". After about 20 files I start bumping into name collisions because I have recorded many sounds that fit the description of "Wind in trees, bright, gusty". Renaming them with XYplorer it's very annoying because I have to
a) manually add number suffixes from the start to avoid future name collisions
b) remember at what number suffix I am currently going with ALL files (which very hard and consumes lots of brain energy)
With an option to just automatically add +1 to the suffix or create a suffix if none is there would just save very much time and more importantly much less annoyance.
Also, I simply do not understand what is good about a window that just says "Error!" and where you have to manually press a 'Ok' button so you can manually go fix the error yourself. So much of XYplorer revolves around the idea of automating file management and making things quicker and easier, precisely so you wouldn't have to do things manually! I do not see a downside to having a small button or two to offer some kind of automatic solution to a name collision in this way. I sincerely think that there is no risk of "feature bloat" or something that would make inline renaming more difficult for some people if there were a few more options in the name collision error screen.
My 2c.
Re: New backup name collision functionality for normal renames
Posted: 03 Dec 2010 18:52
by admin
Makes sense.

Re: New backup name collision functionality for normal renames
Posted: 04 Dec 2010 17:21
by admin
Check out v9.80.0011 ...

Re: New backup name collision functionality for inline renames
Posted: 04 Dec 2010 20:30
by MCS
Yay, that is awesome!! I think this beta implementation is already very good, simple, effective, intuitive and fast! Perfect for my needs, thanks a lot, I am sure other users will like this as well!!!

Re: New backup name collision functionality for inline renames
Posted: 05 Dec 2010 11:47
by zer0
I'm very much against having "Overwrite" in the dialogue there. It's not possible to undo, it's not in the RB to recover from. A slip of a finger can cost dearly when it's least wanted. Personally, I never want to overwrite when doing inline rename, just when copying/moving.
P.S. There may be a refresh issue that causes 2 files with the same name to co-exist as per image below...

- overwrite_glitch.PNG (67.31 KiB) Viewed 2960 times
Re: New backup name collision functionality for inline renames
Posted: 07 Dec 2010 17:21
by jayfischer
I just wanted to says thanks for the inline rename overwrite. I do lots of file management and this will cut out a few steps. I have already used it countless times.
For those of us who use it - I hope you consider an option to turn off confirmation.
Re: New backup name collision functionality for inline renames
Posted: 07 Dec 2010 17:32
by admin
jayfischer wrote:I just wanted to says thanks for the inline rename overwrite. I do lots of file management and this will cut out a few steps. I have already used it countless times.
For those of us who use it - I hope you consider an option to turn off confirmation.
Aha, so here we have the second user who admits he uses overwrite. Interesting, me myself I'm not sure if I will ever need this.
However, I think zer0 is right about the risk and the confirmation should stay. I might add a tweak to turn it off...
Re: New backup name collision functionality for inline renames
Posted: 07 Dec 2010 17:50
by admin
Next version has this tweak:
RenameOverwriteNoConfirm=1
Re: New backup name collision functionality for inline renames
Posted: 07 Dec 2010 20:43
by jayfischer
If I knew how helpful this would have been (inline rename overwrite) - I would have begged for it a long time ago.

I always had to delete the file first (after initially getting a dialog telling me there is a collision) - now poof one step - bye bye old file.
Thanks for the tweak. One less step.