Thanks for the update! I've managed to make the input persistent. Please see attached diff (modification of yours) if it works :).

Thanks for the update, Martin! And sorry it took me so long to dive in. I like it but I'd actually prefer the idea of Alex - keep all the settings in search dialog. I have modified your diff and made 2 screenshots.

Sorry, I've found a bug. During today Krusader use with your patch, there is reproducible crashing when using Synchronizer. When clicking "Compare" in Synchronizer dialog Krusader crashes. I'll have time to more closely look into that tomorrow.

Hi! Thanks for your interest and code! I like it. Sometimes I also don't want to search in .git directories and this change will solve this, so this is great!

I hope you remembered to revert locally the commit.

Of course I didn't, sorry. But now I did. I reverted the KGlobalAccel commit, tested that previous bugs reappeared, then applied this patch and tested again - bugs are gone.

I've tested meta+shift+arrow, alt+shift+arrow, meta+shift+PrtSc and they are working for me, thanks! So far I didn't notice any regressions. I'll keep this version around and will report problem if I see one.
Unfortunately I'm unable to properly review the code itself since I have no knowledge in this area.

Sorry, to be a bit late, but after updating to kwindowsystem 5.38, global shortcuts "meta+shift+<any_arrow_key>" and "alt+shift+<any_arrow_key>" stopped working on my system (Arch Linux). They can be configured no-problem (they are recognized and saved in configuration), but they do nothing afterwards. I'm writing it here because I've tracked the problem down to this commit. Is it reproducible on your side?

I've noticed a regression after this push. Creation of new directory no longer focused the new directory. This should now be fixed in git with commit https://phabricator.kde.org/R167:ac22d0fc4412cc9a2f9130ba85184817c1667094. I didn't want to bother you with another review request. If there are another issues with this, I'll be happy to fix them.

Thanks a lot for your thorough testing :).

Thanks for testing. Committed without the commented code line mentioned by Toni, thanks for pointing that out!

Sorry, second iteration. Added support for absolute paths (starting with "/") - such path is resolved from root folder. Also works for remote filesystems. Tested on local fs and FTP.

Toni, as always, thanks a lot for your testing!

Thanks for testing, Toni! This is what I needed. Here is a fix for your findings :).

Thanks Toni! :)

Thanks for testing it out, Alex. Finally I've got to this. In order to find and address the scrolling issue - some refactoring has been done:

• small code simplifications and deduplications throughout the lister.cpp (there is still room for further deduplications)
• replaced new & delete char* cache in favour of safe QByteArray
• removed constant updating of file state and position (updates only when search is in progress)
• added tun of const
• increased cache size -> which fixed issue with searching up the document (previously it found only some of supposed matches)
• fixed scrolling issue
• simplified code for remote file handling

Sorry for my ignorance with the QDialog and memory leak issue, I've now learnt from it:). I believe the code now looks fine, and works. Although I'd rather remove the parent parameter (0) from new DiskUsageGUI call or replace with MAIN_VIEW like Alex was advising.

Looks good to me and works. Thanks for your code! Please see one code comment.

I definitely like this new way better. Thanks Alex!

Thanks for checking on this. I'm using your suggestion because I agree, it should be fixed closest to the source of troubles.

This is perfect! I also wanted to visualize the locked state but couldn't figure out how. This is a very elegant solution. Thanks!

And you don't have to do everything we say.

I know :), but this time I really didn't care that much.

Thanks for feedback! Here is an update with the option.

My apologies, Alex, I must have missed your fix otherwise I'd test my workflow right away. Now I see You have fixed most of the issues. I've found only one edge-case. Loading a profile is reusing opened tabs, so if You already have a locked tab, it is locked before openUrl() is called. Here is the minimal exact steps to reproduce it:

1. start fresh krusader (empty config)
   • we will focus on left panel only for this test
2. go to e.g. Downloads
3. save profile (e.g. "p1")
4. go back to home folder and lock the tab
5. load profile p1 -> You should see 2 tabs now instead of one

Everything still seems to work just fine. Thanks for fixing older gcc compatibility!

One more thing I've changed in the last diff:
When creating a new file in privileged directory, the file is then set to be readable by group and others. This is because kate wouldn't be able to read it later with regular user who managed to create it in the first place. I realize this is controversial so I will gladly remove this change if we agree on that. Probably the best approach would be to ask for permission to read it with another KAuth action, right?

Thanks for noticing the security issues! And sorry for the pause. Here is an updated diff which should ensure that QFile is using relative path. I've managed to reduce the use of absolute paths to this state - strace (saving privileged example2.txt file inside ~/Downloads):

chdir("/home/kotelnik/Downloads")       = 0
stat("example2.txt", {st_mode=S_IFREG|0640, st_size=1085659, ...}) = 0
getcwd("/home/kotelnik/Downloads", 4096) = 25
getpid()                                = 3343
open("/home/kotelnik/Downloads/example2.txt.TJ3343", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = 10
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
lseek(10, 0, SEEK_SET)                  = 0
close(10)                               = 0
open("/tmp/kate.nS3280", O_RDONLY|O_CLOEXEC) = 10
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
fstat(10, {st_mode=S_IFREG|0600, st_size=1085661, ...}) = 0
open("example2.txt.TJ3343", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 11
[...]
stat("example2.txt", {st_mode=S_IFREG|0640, st_size=1085659, ...}) = 0
access("example2.txt", R_OK)            = 0
access("example2.txt", W_OK)            = 0
access("example2.txt", X_OK)            = -1 EACCES (Permission denied)
chmod("example2.txt.TJ3343", 0640)      = 0
fchown(11, 33, 33)                      = 0
rename("example2.txt.TJ3343", "example2.txt") = 0

One not-nice part in code is opening and immediately closing the QTemporaryFile (the only use of absolute path). Then tempFile is opened again with relative path and written to like before. I wanted to make use of the convenient way of creating unique temporary filename. Other suggestions are welcome :).

Understood and implemented by switching to "current directory" where the final rename is taking place. This way I could use filenames only rename. Hopefully I didn't miss anything.

Very nice! I didn't find any issues. Thanks, Alex :).

Thanks for noticing all these security issues!

Updated diff based on Fabian's advisory. Thanks, Fabian!

One more question - is it necessary to show the checksum to the user? I don't see what it would be good for, but I'm probably missing something.

Sorry for answering after a longer time. I need to be sure I understand everything correctly:

Alex, thanks a lot for making the release and updating the corresponding wiki!

I've created a follow-up diff D5394 and added every subscriber from here. I hope it wasn't too invasive of me.

I like "Stiff Challenges" very much! Agreed, 2.6.0 version makes more sense.

Sorry for my late reaction. Yes, this is nicer and working. Thanks, Alex! To avoid waiting of each other: You do the commit :).

Sorry, for the late response. Yes, this is good, I like it. Thanks!

Sure, no problem :).

Updating diff with refinements based on David's insights, thanks David!

I agree. Probably lame but how about "Job-Man Show"? :)

it should work as it is now, or I am mistaken?

I believe the latest diff update is indeed making use of atomic rename. I will roughly summarize what the code currently does:

1. First try to open QSaveFile, if succeeded -> finish writing as before the patch
2. If opening QSaveFile fails KAuth action is called for creation of a temporary file in the same directory as the original target file
3. Then writing to this file is performed as regular user (same as before the patch)
4. Finally, second KAuth action is called to atomically rename the temporary file

I know there is a lot of other stuff going on. So just to be sure: am I supposed to do something else - are we waiting for me?

Very nice! Thanks Alex! :)

I agree, no objections.

Good point! I was about to say that the target folder is in most cases non-writable without elevated privileges. But we can actually use KAuth action twice, for 2 simple jobs:

1. Create temporary file right next to target file, set current user as owner, so it is writable without root privileges.
2. And after storing file contents outside kauth helper binary. atomically rename the temporary file.

Thanks a sorry for all the rookie mistakes. I tried to fix the problems You mentioned:

• QT->Qt
• get rid of useless streams
• no more setting permissions and sync-to-disk when using QSaveFile
• using of QMap::insert (should I use an initializer list instead?)

Thanks a lot for all the thoughts and suggestions! I tried to work them in, but I need help with some of them.

Understood and agreed, kauth_ktexteditor_helper it is :).

Thanks for your guidance and for having the patience with me. QScopedPointer was indeed very useful.

Good point, thanks! I now the helper is really light-weight. Helper is now only moving a temporary file and setting permissions/owner.

I've learnt a few things about autotests (KTextEditor::EditorPrivate::unitTestMode() was really helpful, thanks!). I managed to create a test case, which allowed the code to go through KAuth action. But I was unsuccessful to finish it to my satisfaction - I couldn't come up with a solution where in case of unit testing KAuth dialog is not shown and just allows the execution. action.exectute(ExecutionMode::AuthorizeOnlyMode) will not help here since it does not really execute the action. I also tried to create "autotestsave" action alongside existing "save" action and set it to be always allowed. Then triggered it only from unit test. This worked well but I don't find it safe having such action available in non-testing runtime.

After reading though bug mentioned by Luigi and this QT bug (https://bugreports.qt.io/browse/QTBUG-56366) I'm not so convinced that we want to directly write to file in order to maintain owner, because we would loose atomicity of the save operation. I've updated the diff so at least group is restored to the previous one if owner cannot be changed. I think loosing group was the most painful outcome of QSaveFile design.

I think that leaving it as it is is not a solution

In that case, I favour the second option (direct write to file).

Next iteration, still without autotests, I need to study them more.

Thanks for all the feedback!

I once again updated the diff - I've only renamed 2 variables to better reflect what they mean:
readAction -> saveAction (I copied that one from tutorial page and forgot to rename)
dataToWrite -> dataToSave

I missed this one - thanks, Wladimir. Fixed.

I value security over features.

Me too, so I tend to agree with removal of root-mode, but Wladimir already improved current state of Krusader security. So I say lets keep it for a little while. In the meantime I will work on an integration with KAuth for some actions. I just managed to integrate it in KTextEditor ( https://phabricator.kde.org/D4847 ), so one can now edit write-protected document in our internal editor being conveniently asked for password on save.