Of course the message should have the usual "Don't show again" checkbox.

I think I could live without a warning message, if the item is named 'Duplicate here' (or 'Duplicate Here'?) to clarify that you shouldn't use it to get a duplicate elsewhere.

In D8208#591262, @cfeck wrote:

I think I could live without a warning message, if the item is named 'Duplicate here' (or 'Duplicate Here'?) to clarify that you shouldn't use it to get a duplicate elsewhere.

Sure, I can do that. Makes sense.

@fvogt "test.foo" becoming "test.foo copy" is intentional because .foo isn't a known valid extension, and it's valid for files to have dots in their names. In general the approach of using QMimeDatabase supports this, solves the problems of using QFileInfo that @pino pointed out, and also allows seamless support for filename extensions with two dots in them (e.g. tar.gz).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

In D8208#591704, @ngraham wrote:

@fvogt "test.foo" becoming "test.foo copy" is intentional because .foo isn't a known valid extension, and it's valid for files to have dots in their names. In general the approach of using QMimeDatabase supports this, solves the problems of using QFileInfo that @pino pointed out, and also allows seamless support for filename extensions with two dots in them (e.g. tar.gz).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

The case preserving issue is more severe than the issue with unknown extensions, so if that's fixed, using QMimeDatabase is IMO fine. Maybe with a fallback to completeSuffix if it didn't have an entry.

In D8208#591704, @ngraham wrote:

@fvogt "test.foo" becoming "test.foo copy" is intentional because .foo isn't a known valid extension, and it's valid for files to have dots in their names. In general the approach of using QMimeDatabase supports this, solves the problems of using QFileInfo that @pino pointed out, and also allows seamless support for filename extensions with two dots in them (e.g. tar.gz).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

Why trying to append 'copy' in the base name whith possible headaches while you could simply do something like 'Copy N#1 of /original file name/' ?
The only thing to test would be if the filename starts with a dot and and keep it as first.

In D8208#591931, @fazevedo wrote:

In D8208#591704, @ngraham wrote:

@fvogt "test.foo" becoming "test.foo copy" is intentional because .foo isn't a known valid extension, and it's valid for files to have dots in their names. In general the approach of using QMimeDatabase supports this, solves the problems of using QFileInfo that @pino pointed out, and also allows seamless support for filename extensions with two dots in them (e.g. tar.gz).

If I go back to using QFileInfo to chop up the file into filename + extension, then there's the difficult choice of what kind of file to fail on: If I use QFileInfo::suffix(), it will fail for extensions with two dots like .tar.gz; if I use QFileInfo::completeSuffix(), that fails for files with dots in their names outside of the extension.

Each approach has drawbacks. Which would you find acceptable?

Why trying to append 'copy' in the base name whith possible headaches while you could simply do something like 'Copy N#1 of /original file name/' ?

That's what windows (xp, no idea about newer) does as well.

I can do that, sure. But IMO there's a UX problem when you append "Copy of" to the beginning rather than the end. Imagine that you have a file that starts with a Z and you duplicate it. The duplicate appears near the top of the window because it begins with C. If the current view is scrollable, view scrolls up to the top to show you the newly duplicated file. This causes you to lose your place in the view, which could be annoying if you were planning to do something else with another adjacent file or perform another operation on the original file (perhaps to duplicate it a second time to perform some A/B testing on two duplicates with slightly different changes, for example). For this reason, I prefer the macOS behavior of appending "copy" to the end of the filename, not to the beginning.

How about I fix suffixForFileName() to preserve case?

That would be nice too. :)

Hmm I don't think I should change the behaviour of QMimeDatabase after all.

https://lxr.kde.org/source/kde/kdeutils/ark/kerfuffle/createdialog.cpp#0106 does

const QString detectedSuffix = QMimeDatabase().suffixForFileName(fileName);
if (currentMimeType().suffixes().contains(detectedSuffix)) {

which would break if case was preserved.

fileName.right(extension.size()) is exactly the way I almost-fixed this in Qt, so it's the right thing to do here instead :)
http://www.davidfaure.fr/kde/qt_preserve_case.diff for the record.

In D8208#592084, @ngraham wrote:

I can do that, sure. But IMO there's a UX problem when you append "Copy of" to the beginning rather than the end. Imagine that you have a file that starts with a Z and you duplicate it. The duplicate appears near the top of the window because it begins with C. If the current view is scrollable, view scrolls up to the top to show you the newly duplicated file. This causes you to lose your place in the view, which could be annoying if you were planning to do something else with another adjacent file or perform another operation on the original file (perhaps to duplicate it a second time to perform some A/B testing on two duplicates with slightly different changes, for example). For this reason, I prefer the macOS behavior of appending "copy" to the end of the filename, not to the beginning.

Well, that depends on the current sorting mode, right? If I have sort-by-modified then the duplicate file will jump to the top of the view even if it has the "copy" suffix rather than the "Copy of" prefix, no?

Normally this shouldn't happen, since this uses CopyJob which preserves the mtime of the file.

In D8208#592689, @dfaure wrote:

Normally this shouldn't happen, since this uses CopyJob which preserves the mtime of the file.

Right. Sort-by-created then :-)

In D8208#592667, @elvisangelaccio wrote:

Well, that depends on the current sorting mode, right? If I have sort-by-modified then the duplicate file will jump to the top of the view even if it has the "copy" suffix rather than the "Copy of" prefix, no?

If you prepend "Copy of," then it jumps around when you're sorting by Name or Creation Date.

If you append "copy," then it only jumps around when you're sorting by Creation Date.

I agree, append is better.

Friendly Dolphin ping. :)

I can't figure out how to make the rename operation work right now; see the FIXME: in the code. We can do it later in another patch, or else maybe someone could help me with it here.

I don't get why we want to start a rename operation at all, tbf.

Anyway, it doesn't seems to work for me. Can you update the test plan?

Done.

@elvisangelaccio ping

Sorry for the delay, I moved to a new house. I'll resume all pending reviews soon.

Congratulations!!!! Take all the time you need.