XYplorer Beta Club

If I drag & drop a file from one tab to another and choose "Copy/Move Here with Suffix Number" the file - at least on my computer - is copied/moved without renaming it. "Copy Here with Suffix Number" without switching the tab works without problems.

Confirmed.

That's as expected. The suffix number is only added when a same-named file exists in the target.

Proof: drag the same file again to the same tab and the number will be added!

admin wrote:That's as expected. The suffix number is only added when a same-named file exists in the target.

Oh, I see...if it is intended that way.

So maybe this time it's the documentation aspect that needs a tweak? And not the code! I like those easy ways to resolve "problems"..

Update: Thus, I just added this sentence "The suffix number is only added when a same-named file exists in the target." to the related wiki section.

j_c_hallgren wrote:Update: Thus, I just added this sentence "The suffix number is only added when a same-named file exists in the target." to the related wiki section.

Yeah, I see you did that, and I'm not sure it should be done.

I'm sorry guys, but this is a bug to me, not intended behavior. Or, at least, it shouldn't be.

Clearly, you all got this wrong : the feature is called "Move/Copy Here with Suffix Number" and it should do that. What I ask XY to copy with suffix number, I want it to do just that, not to go and decide that the suffix number won't be added after all because there's no such file here already, the sky is blue, or whatever criteria he feels like using.

I did not ask for "Move/Copy Here" where the suffix would have to be added if a file already existed by that name, nor did I ask to move/copy here with optional suffix, and I want what I asked for.

Just like when I say Move/Copy Here with Suffix Date Now/Modified, I want that suffix to be added, because I asked for it, not because there's no such file already or I don't know what.

No seriously, that's not expected, that's a bug, and - sorry Don - but the proof only proves one thing : that it doesn't do what it's asked to do right now, but something else.

jacky wrote:

j_c_hallgren wrote:Update: Thus, I just added this sentence "The suffix number is only added when a same-named file exists in the target." to the related wiki section.

Yeah, I see you did that, and I'm not sure it should be done.

I'm sorry guys, but this is a bug to me, not intended behavior. Or, at least, it shouldn't be.

Clearly, you all got this wrong : the feature is called "Move/Copy Here with Suffix Number" and it should do that. What I ask XY to copy with suffix number, I want it to do just that, not to go and decide that the suffix number won't be added after all because there's no such file here already, the sky is blue, or whatever criteria he feels like using.

I did not ask for "Move/Copy Here" where the suffix would have to be added if a file already existed by that name, nor did I ask to move/copy here with optional suffix, and I want what I asked for.

Just like when I say Move/Copy Here with Suffix Date Now/Modified, I want that suffix to be added, because I asked for it, not because there's no such file already or I don't know what.

No seriously, that's not expected, that's a bug, and - sorry Don - but the proof only proves one thing : that it doesn't do what it's asked to do right now, but something else.

The documentation is lacking, not the function. "Move/Copy Here" always overwrites an existing file.

The caption should be "Move/Copy Here, with Suffix Number on collision", but that's too long.

admin wrote:The caption should be "Move/Copy Here, with Suffix Number on collision", but that's too long.

Yeah, no. I think this isn't right. I mean, I mostly use it on the same folder so I never really noticed this, but as I said I expect this feature to always add a suffix, the same way other feature adding suffixes do work. And they all are regrouped together.

If I "Copy Here with Suffix Number" a file to a folder, I really expect to have a suffix number. Just like I would a date suffix when using such feature.

I know some other features do behave as such : keep the same name, but if already exists then add suffix number. That's true, right, and expected. But not this one, I think to have this feature behave the same is wrong.

By the way, from the Help file, so your words not mine (I put in bold a few things) :

Copy/Move Here With Suffix Number

Creates an auto-serial-numbererd duplicate of the dragged file. The command is available only if exactly one file is drag-dropped, resp., when triggered by keyboard, applies only to the focused file. Examples:
My.txt => My-01.txt
My.txt => My-02.txt (if My-01.txt already exists)
My.txt => My-03.txt (if My-01.txt and My-02.txt already exist)
etc.

See? I would think you're confusing a few things now, because clearly (to me) this feature always intended to add a suffix number, the "if already exists" part only comes in for the actual number to use.

jacky wrote:

admin wrote:The caption should be "Move/Copy Here, with Suffix Number on collision", but that's too long.

Yeah, no. I think this isn't right. I mean, I mostly use it on the same folder so I never really noticed this, but as I said I expect this feature to always add a suffix, the same way other feature adding suffixes do work. And they all are regrouped together.

If I "Copy Here with Suffix Number" a file to a folder, I really expect to have a suffix number. Just like I would a date suffix when using such feature.

I know some other features do behave as such : keep the same name, but if already exists then add suffix number. That's true, right, and expected. But not this one, I think to have this feature behave the same is wrong.

By the way, from the Help file, so your words not mine (I put in bold a few things) :

Copy/Move Here With Suffix Number

Creates an auto-serial-numbererd duplicate of the dragged file. The command is available only if exactly one file is drag-dropped, resp., when triggered by keyboard, applies only to the focused file. Examples:
My.txt => My-01.txt
My.txt => My-02.txt (if My-01.txt already exists)
My.txt => My-03.txt (if My-01.txt and My-02.txt already exist)
etc.

See? I would think you're confusing a few things now, because clearly (to me) this feature always intended to add a suffix number, the "if already exists" part only comes in for the actual number to use.

Other opinions...?

jacky wrote:

j_c_hallgren wrote:Update: Thus, I just added this sentence "The suffix number is only added when a same-named file exists in the target." to the related wiki section.

Yeah, I see you did that, and I'm not sure it should be done.

That's the advantage of a wiki! We can easily revise it as needed...I just thought that, for now, it would be helpful.

jacky wrote:I'm sorry guys, but this is a bug to me, not intended behavior. Or, at least, it shouldn't be.
Clearly, you all got this wrong : the feature is called "Move/Copy Here with Suffix Number" and it should do that. What I ask XY to copy with suffix number, I want it to do just that, not to go and decide that the suffix number won't be added after all because there's no such file here already, the sky is blue, or whatever criteria he feels like using.

After reading these subsequent posts, I'll have to agree with jacky in that it should always add the nbr...I can't think of a reason why it shouldn't...

My point of view: both are right or: no one is wrong - this is not the question for what is right or wrong, but the question for what to expect.
I understand Donald saying "this is copy, and if needed appending a suffix", and understand jacky saying "copy with suffix means with suffix".

So there are 2 questions: what function would be better, and what would be the best name for this? (In this sequence!)
(Or make ist customizable )

PeterH wrote:So there are 2 questions: what function would be better, and what would be the best name for this? (In this sequence!)

Yep, agreed!

On the other hand, I do see the point in function symmetry/consistency. The other neighboring functions (suffix date) always append their thing, so I could live with always suffix a number.

Could you, too, PeterH?

admin wrote:On the other hand, I do see the point in function symmetry/consistency. The other neighboring functions (suffix date) always append their thing, so I could live with always suffix a number.

Oh, I really didn't want to start a debate on principles here, I just wanted to mention an issue I believed to be a bug.

"...so I could live with..." sounds like you really liked the way it was until now, Don. So if it is essential for your workflow, don't change it. I go along with jacky, that the suffix should always be added, but it's really not that essential.

bergfex wrote:

admin wrote:On the other hand, I do see the point in function symmetry/consistency. The other neighboring functions (suffix date) always append their thing, so I could live with always suffix a number.

Oh, I really didn't want to start a debate on principles here, I just wanted to mention an issue I believed to be a bug.

"...so I could live with..." sounds like you really liked the way it was until now, Don. So if it is essential for your workflow, don't change it. I go along with jacky, that the suffix should always be added, but it's really not that essential.

No, I think I never use this function to other places than "here". So I always get my suffix number.

So, you would have found it totally natural and expected, if the copy was appended with "-01" even if there was no collision? Hint: if you say "yes", I'll change the function. It will be less work than changing the documentation anyway!

And IF y'all can't agree, there's always the INI tweak option solution!
I'd go with the "always suffix nbr" as if I didn't want it, I'd use another method/command.