Tested on Fedora 30; it compiles and the bug is not present anymore; during the same test, a Krusader version without this patch was having this problem while the patched one was able to rename the file.

Forgot to add the reference to this revision in the commit message, closed with Shortcuts to move tab

Removed the single tab check in favor of a comment, like proposed by @abika

@abika : this is intentional to define that these two methods do nothing when the panel has just one tab, I can change them with a comment remarking this logic

I thought I had already committed that... changed to a more human macro name

Confirmed by the build (https://build.kde.org/job/Extragear/job/krusader/job/kf5-qt5%20FreeBSDQt5.11/4/warnings12Result/), 51 warnings fixed and 'missing-override' is not in the remaining 57.

Changed in favor of a macro solution (as suggested by Nikita).

In D15376#325404, @asensi wrote:

What do you think about creating a specialized version of UDSEntry, e.g. KrUDSEntry? This way the code:

Added flag for GCC as default

I've looked at the Clang behaviour: the -Winconsistent-missing-override flag is always set (Debug, Release and none), so GCC should be set the same. My initial thought was to not users to be worried; on a second thought, every user is a tester too.

I've tested with clang compiler and no additional flags are needed, on a clean Fedora 28 I used:

The use of a Macro was my second way to solve this, but I thought it would add more complexity to the code; instead, this patch makes the code unclear to read.

I updated the diff to v2 to fix spaces as requested.

I tried to break as less things as possible. I have a little knowledge of i18n but I think that merging the text will require a new strings translation; from my point of view, translations magically appear when I compile. I can put a comment in the final commit to let others to know that it can be refactored.

All tests fine, it also work with zip:/ protocol

Tested on Slackware 14.2 with gcc 5 and Fedora 25 with gcc 6

Solved in https://cgit.kde.org/krusader.git/commit/?id=4df7f97cdd2a3a8234b54dcbb205c9e6349d564c

Yes, kiso is missing the option we added to krarc (see https://groups.google.com/forum/#!topic/krusader-devel/mN8uyxBj4Wg).

What distro do you have? I'll dive into KIO to see where the problem is.

This patch can be applied on master; is this helpful, or the rework on VFS will make it obsolete?

Great work!!! Sorry for not being present lately, but I have some issues with my pc an my work keeps my spare time lower.

I tried only on zip files, but I have to check all kind of archives supported by 7za. To stop the kio, I use error(ERR_CANNOT_RENAME). This doesn't permit KIO to switch to copy+del or get+put.

You can't pass a QList of urls to every program, not every program likes it so no files are opened at all.

This is the first attempt to use 7za to rename a file inside an archive. It works, but we have to do more checks.

I forgot non-empty folders. My solution can't be useful anymore. So I turned again on zipnote and looking to a possibile method with other types of archive, I've found that newer versions of 7za can rename files inside archives (both .zip and .7z).

A fix could be to change in krusader/Panel/panelfunc.cpp:215

Using D2603, I was able to find where to problem is:

I agree too. The KrCalcSpaceDialog pops up after a while when calculating directory space. It is a way to know that Krusader isn't freezed. When done, the popup closes and the <DIR> string is changed with the dir space. Anything to say "hey, I'm working, but I'm not freezed" is good to; like when krarc reads a file.

Atm, this task is almost a discussion, if you have already done some work, no problem. I'm focused on kio_iso T3490 (the solution to recognize path with symlinks, the other one is trivial).

In T3419#48717, @asensi wrote:

I agree, too, and maybe with those VFS improvements... important bugs like

A problem renaming a file that is inside an archive
https://bugs.kde.org/show_bug.cgi?id=350028

would be solved.

I've found two possible solutions:

This explain very well the problem. We can't use kio_krarcProtocol::copy to rename an item inside an archive, and krArc doesn't have a rename method, so we must implement it.

The problem starts here: the job is started but it is never completed.

I agree, the analysis is right; it is also needed to search into archives (because they have the tar: krarc: or zip: scheme).

In the first days of porting, I thought Extragear software was merging into Applications and no one never changed it.

CTRL+DEL works fine and it doesn't seems to conflicts with other actions (afaik, it is used to delete the whole next word, but we're not in an edit mode).