If new text or html document is created using the right click menu, then ALL permissions are set to read and write (my default umask is 022). Have tested touch from shell, kwrite (from shell and menu) etc and they give the correct permissions. Reproducible: Always Steps to Reproduce: 1. start dolphin 2. right click in any home folder -> create new text file 3. right click - view properties/permissions Actual Results: mask 000 Expected Results: mask 022
Might be related to Bug#356198? I.e. KIO cannot copy over the actual template file. Is the issue fixed if you copy the files from /usr/share/kde4/templates/ to /usr/share/templates/? For this case TextFile.desktop and .source/TextFile.txt in particular, the latter should of course go into a .source sub folder. At least that's my experience here (openSUSE 13.2 with the latest versions from KDE:Frameworks5 and KDE:Applications).
Solved! I Did as you say and can confirm permissions are now set correctly, and in addition (wrt to Bug#356198) the files are now 'formed correctly' as e.g. text etc. Thanks! *** This bug has been marked as a duplicate of bug 356198 ***
Thanks for confirming! FYI, we (openSUSE) added exactly that (explicitely install the files to /usr/share/templates/ again) as workaround to our kio package, this will be in the upcoming Frameworks 5.19.0 update for Leap 42.1 too.
solution (maybe) causes new problem. now any file i create is unable to be searched, unless baloo is disabled. (i have spend all day) creating files etc and testing. if i copy an old file remove contents and write qwerty and search for string all is good. If i try to create a new file with same word content, search from dolphin, will not find.
(In reply to nicholas from comment #4) > solution (maybe) causes new problem. > > now any file i create is unable to be searched, unless baloo is disabled. Definitely unrelated to the original problem IMHO. But apparently baloo doesn't notice the newly created file. Try to disable baloo and enable it again, or delete the index in ~/.local/share/baloo/, and it should see it after a reindex. If not, please report a new bug against baloo.
Git commit dc8588efe72a5ca7670d0371537d99a0d4c690f5 by David Faure. Committed on 24/07/2016 at 09:41. Pushed by dfaure into branch 'master'. KNewFileMenu: fix copying template file from embedded resource Fix from Wolfgang Bauer, unittest from me. FIXED-IN: 5.25 REVIEW: 128510 M +12 -2 autotests/knewfilemenutest.cpp M +3 -1 src/filewidgets/knewfilemenu.cpp http://commits.kde.org/kio/dc8588efe72a5ca7670d0371537d99a0d4c690f5
Though the copying of the template file from the embedded resource is fixed now, the permissions of the newly created file are still wrong unfortunately, the file gets rw-rw-rw though the umask is 022. So it seems that KIO::StoredTransferJob/KIO::storedPut() doesn't respect the umask (KNewFileMenu sets the permissions to -1 which means "default permissions"). It works fine when copying actual files from /usr/share/templates/, in this case KIO::CopyJob/KIO::copyAs() is used, the file gets rw-r--r-- with an umask of 022 even if the source file has rw-rw-rw. Haven't investigated deeper yet though.
Changing product, this is not a bug in dolphin.
Git commit b61fcd1878d4df39f57b3e947885e63cba670843 by David Faure. Committed on 06/08/2016 at 21:31. Pushed by dfaure into branch 'master'. Fix KIO::put("file:///path") to respect the umask. (Bug introduced when porting kio_file to QFile, in KF 5.0) This fixes permissions on files created with "Create New...". FIXED-IN: 5.25 M +23 -1 autotests/knewfilemenutest.cpp M +5 -9 src/ioslaves/file/file.cpp http://commits.kde.org/kio/b61fcd1878d4df39f57b3e947885e63cba670843