1) write data to a file in current folder (download a large file, etc) for long enough period of time 2) F2, or Context menu > Rename, to rename any file in current folder After that, the 'Rename' function will not work, until I restart Krusader, or by (randomly) stop and resume the process of writing data to the file.
Confirmed only in case at the step #2 I try to rename the file that's being updated. Renaming other files doesn't trigger the issue. Also, Rename works on the other panel without a problem even if the issue is triggered.
still happens in 2.7.1 and seems to be restricted to panel where you renamed if you change to a new directory you can rename again
*** Bug 408061 has been marked as a duplicate of this bug. ***
(In reply to Nikita Melnichenko from comment #1) > Confirmed only in case at the step #2 I try to rename the file that's being > updated. Renaming other files doesn't trigger the issue. Also, Rename works > on the other panel without a problem even if the issue is triggered. Are you sure? I can see behavior as written in the initial description (and as reported in issue#408061). It means, no file in the given directory can be renamed (and not the file which is being written). Thanks.
I'm sure. Just tested again. Be sure to test with v2.7.1 or higher. My way to repro: $ for ((i = 0; i < 1000; i++)); do echo $i > $i.txt; done $ cat /dev/urandom > 000.txt Then go to the dir in Krusader. I can rename any file except 000.txt while the `cat` process is running. Once I try to rename 000.txt, it stops working for _any_ file. It's actually restricted to the tab, not even the panel. I'll try to investigate it soon.
(In reply to Nikita Melnichenko from comment #5) > I'm sure. Just tested again. Be sure to test with v2.7.1 or higher. Create a file _after_ (during) writing to a file and try to rename it, it will fail too. In other words, yes, files created _before_ not-completely-written file can be renamed. Tested on Krusader 2.7.1. Thank you.
I have a fix for this bug, however it has a certain side effect related to editing the next item to the one that's being updated. I see workarounds in the code regarding the next item selection and I believe the underlying model is implemented improperly. I'm exploring if I can fix this as well. Just FYI.
(In reply to Nikita Melnichenko from comment #7) > I have a fix for this bug, however it has a certain side effect related to > editing the next item to the one that's being updated. I see workarounds in > the code regarding the next item selection and I believe the underlying > model is implemented improperly. I'm exploring if I can fix this as well. > Just FYI. Great news, thanks a lot for looking into this issue!
You are welcome. I fixed the bug in the list model as well. The proposed fix is here: https://phabricator.kde.org/D22431 Feel free to test the patch on the master branch and share your feedback.
(In reply to Nikita Melnichenko from comment #9) > You are welcome. I fixed the bug in the list model as well. Sounds perfect, thanks a lot! > The proposed fix is here: https://phabricator.kde.org/D22431 > Feel free to test the patch on the master branch and share your feedback. Unfortunately, I am not skilled enough to test it myself so I hope it will be released soon. Thank you.
Git commit 34764ed6dc1b4d667d09d751faa90408fb7e2de9 by Nikita Melnichenko. Committed on 20/07/2019 at 06:11. Pushed by melnichenko into branch 'master'. Fixed lost editor when file is updating and the list model to correctly handle next item Summary: The lost editor issue (see the bug for reference) was happening because the editor hasn't been closed in the view but the item is deleted and re-inserted. The fix is to close any editor attached to an item before removing the item. The workaround for next item current selection introduced in 2fbd49f0 is no longer needed due to the fix of the underlying issue in the list model. Without the fix, the lost editor issue is also observed when editing the file which is next to the updating one. FIXED: [ 392750 ] After trying to rename the file that's being updated, rename function stops working on any file on this tab Differential Revision: https://phabricator.kde.org/D22431 M +7 -9 krusader/Panel/PanelView/krinterview.cpp M +4 -15 krusader/Panel/PanelView/listmodel.cpp https://commits.kde.org/krusader/34764ed6dc1b4d667d09d751faa90408fb7e2de9
Git commit ca225e2912843125a626fad711211f5685b60fcf by Nikita Melnichenko. Committed on 20/07/2019 at 06:53. Pushed by melnichenko into branch 'stable'. Fixed lost editor when file is updating and the list model to correctly handle next item Summary: The lost editor issue (see the bug for reference) was happening because the editor hasn't been closed in the view but the item is deleted and re-inserted. The fix is to close any editor attached to an item before removing the item. The workaround for next item current selection introduced in 2fbd49f0 is no longer needed due to the fix of the underlying issue in the list model. Without the fix, the lost editor issue is also observed when editing the file which is next to the updating one. FIXED: [ 392750 ] After trying to rename the file that's being updated, rename function stops working on any file on this tab Differential Revision: https://phabricator.kde.org/D22431 (cherry picked from commit 34764ed6dc1b4d667d09d751faa90408fb7e2de9) # Resolved conflicts: # krusader/Panel/PanelView/krinterview.cpp M +7 -9 krusader/Panel/PanelView/krinterview.cpp M +4 -15 krusader/Panel/PanelView/listmodel.cpp https://commits.kde.org/krusader/ca225e2912843125a626fad711211f5685b60fcf