KDE Frameworks 5.46.0 QT 5.9.4 Krusader 2.7.0 Reproducing: Open fro menu File -> New Text File What we get: New file with 600 permissions What we expect: New File with 644 permissions like in Dolphin
I confirm on my end. Same for Shift+F4. Permissions should be the same as when you touch the file and depend on umask setting.
Confirmed using Kubuntu 18.04; this doesn't happen when creating folders, by the way.
kde5-krusader-2.7.1 Bug is still actual
Heck! I cannot find out why it's not working. It should done by krusader/Panel/panelfunc.cpp:522 > KIO::CopyJob *job = KIO::copy(QUrl::fromLocalFile(tempFile->fileName()), > job->setDefaultPermissions(true); The same way it is done by KIO for Dolphin filewidgets/knewfilemenu.cpp:615 > KIO::CopyJob *job = KIO::copyAs(uSrc, dest); > job->setDefaultPermissions(true);
Maybe you should write a test app? Also I couldn't find what the default permission are in the kio docs.
Alex, the problem is not with the KIO::copy code. It's QTemporaryFile which is created with the restricted permissions. I think we should refactor the code and possibly remove the QTemporaryFile calls. I'm not yet sure how to deal with remote file systems. Another option is not creating a file and let editor save it. I checked that it saves with proper permissions.
You're right Nikita, I missed that. But this means that KIO::CopyJob::setDefaultPermissions() is not working. The documentation says it for exactly this use case - having umask applied when copying temporary files. And AFAIK there is no way to create a file with KIO (KIO::open() seems to be only for opening existing files). All KIO code I have seen also uses the way to copy already existing files to a final destination.
A patch that sets the permissions to 644 until the bug in KIO is fixed: https://phabricator.kde.org/D19277
I checked KIO::CopyJob::setDefaultPermissions and follow up code and this piece looks suspicious: filecopyjob.cpp: 501 if (d->m_mustChmod) { 502 // If d->m_permissions == -1, keep the default permissions 503 if (d->m_permissions != -1) { 504 d->m_chmodJob = chmod(d->m_dest, d->m_permissions); 505 addSubjob(d->m_chmodJob); 506 } 507 d->m_mustChmod = false; 508 } Haven't debugged though since KIO likely requires special debugging environment but according to the code (d->m_permissions == -1) is exactly happens after we call setDefaultPermissions and then chmod is never called. So far I think the best way is to handle local files differently and create them with QFile to get the default permissions. The downside is that it should be handled carefully given the async nature of that code. Probably, we should look more into the Dolphin code. They get around it somehow.
Fixed with commit dce5c5057c85a2d42e161f0dbd2dc6cd26c17a32. Bug 404777 in KIO is still open.
Git commit 262a96c795c702c7568803b64d3c67df9625364e by Nikita Melnichenko. Committed on 01/07/2019 at 07:10. Pushed by melnichenko into branch 'stable'. Fixed new file permissions Combined and adapted the following commits from master: dce5c5057c85a2d42e161f0dbd2dc6cd26c17a32 c6db82bcb2d61e34e1c8bfb87aade25c7fed9093 FIXED: [ 395609 ] New Text File is created with 600 (-rw-------) permissions Differential Revision: https://phabricator.kde.org/D19277 M +3 -6 krusader/Panel/listpanel.cpp M +1 -1 krusader/Panel/listpanel.h M +2 -3 krusader/Panel/listpanelactions.cpp M +2 -2 krusader/Panel/listpanelactions.h M +2 -11 krusader/Panel/panelcontextmenu.cpp M +0 -2 krusader/Panel/panelcontextmenu.h M +53 -41 krusader/Panel/panelfunc.cpp M +4 -4 krusader/Panel/panelfunc.h https://commits.kde.org/krusader/262a96c795c702c7568803b64d3c67df9625364e
*** Bug 413389 has been marked as a duplicate of this bug. ***