This is not smb specific issue. This is true for all remote KDE protocols, e.g. ftp sftp etc.

I think it'll need to be fixed in each ioslave though.

I don't think so. The slaves aren't what suggests the alternative names and dolphin/kio supposedly already have listed the dir, so they would already know if 'Foo' exists so the default can be 'Foo (1)' instead.

KIO simply chooses not do that for !local files

    if (defaultFile.isLocalFile() && QFile::exists(defaultFile.toLocalFile())) {
        text = KFileUtils::suggestName(directory, text);
    }

Which at a glance is because KFileUtils::suggestName (from kcoreaddons) has no way to check remote urls. I would think the suggestName function needs to take a special indirection object as argument.

e.g. a function

KFileUtils::suggestName(directory, text, /* exists checker */ [](QUrl url) { QFileInfo::exists(url) } );

obviously just an example, the actual function would check the protocol and route through kio as necessary.
In any case the point is that the conflict check needs moving out of kcoreaddons and into the caller (in our case KIO) so protocol support can kick in.

Moving to KIO. Technically this needs fixing in kcoreaddons first though.

It looks like there is a KIO::suggestName() but it was deprecated some time ago, https://phabricator.kde.org/D22637

I'll see if I can extend it to work with remote files/dirs too and then un-deprecate it...

Please disregard my previous post (<insert lame excuse here>) :)

Indeed, KFileUtils::suggestName() checks if the file exists so that it can recurse and suggest a different name (incrementing d in "new folder (d)"). The thing is KFileUtils is in KCoreAddons which is tier1, it can't #include KIO... I think suggestName() should only suggest a name based on the args that are passed to it, but that means complicating the code in the caller....

Note my suggestion in Comment #3. KCoreAddons doesn't need to depend on KIO its API just needs to allow the caller (i.e. KIO) to pass in some abstraction (e.g. a lambda) to abstract the exists() check.

I did read your comment#3, I just imagined that that lambda will use KIO::stat(); can that work if KCoreAddons can't depend on KIO?

Yes it'd work fine. The lambda is part of KIO's library in that scenario. You'd essentially pass a glorified function pointer to KCoreAddons. KCA doesn't need to know anything about it other than what address to call with what kind of arguments. You can also think of the lambda as a class StatInterface that is pure virtual within KCA and implemented in KIO and then passed as a pointer to KCA. KCA knows how to deal with a StatInterface, the specifics of how that StatInterface is implemented is of no importance.

I tinkered with this a bit, in KNewFileMenu itself (if it worked I would then modify KFileUtils::suggestName). The problem is if the stat job is async, it's too late as it gets a result _after_ the new folder dialog has already shown up with "New Folder".

Using exec() seems to work but I found this comment from the original KIO::suggestName() https://cgit.kde.org/kio.git/commit/?id=65010677ff357bbbd48863a3359ca9f990570267:
// TODO: network transparency. However, using NetAccess from a modal dialog
// could be a problem, no? (given that it uses a modal widget itself....)

IIUC, it's talking about it starting an event loop (NetAccess is synchronous), which is what exec() would do, which is a source of crashes...

Would that still be a problem if suggestName as a whole was made async?

I can't say off-hand :), I'll do some more testing...

This was fixed by https://invent.kde.org/frameworks/kio/-/commit/13ef93f0b84217fee911f870b8ce6733a52fabf4