Version: 1.7.1 (using KDE 3.3.1, (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-3) OS: Linux (i686) release 2.6.9-1-686-smp (This may touch various other bugs as well.) I have several logins with their Mail folder as a symlink to on Mail folder. Kmail in any login other than root or the owner of the Mail folder will see No subject/Blank emails. The actual content is not destroyed. How should this work? If the login has group read permission, he should be able to read the mails correctly. If the login has group read/write permission, he should be able to read, move, delete the mails correctly. If not, then NOTHING should be displayed and an error box or text in the content pane simply saying "Permission denied" or similar be displayed.
Could you check if the user is allowed to access the folder and subfolders (group x-bit), if the group bits are set to rwx and the user is part of the group it should work. I'll implement a nice error box about missing permissions soon...
Group permissions are rwx on my login. They should be set on other logins by a sudo (other logins did not have sudo permissions so this was not occurring). My point is that KMail, Kabc, Konqueror, etc., should leave the permissions alone and when saving messages, entries, etc., follow them. Assume the user set this up for some reason. If incorrect, then the error box will tell him. This had been working without my sudo startup commands but got rebroken, I believe.
If this is about attachments being saved with a fixed umask, then there is an other report about this. Let me know.
Not relevant here.
Second login which has group read/write permissions to the messages cannot read them. Selected message gets changed to "no subject" and blank. If I then start Kmail as the owning user, the messages are just fine. Sudos on login to assure user1:user1 rw ownership are successfully run. User2 is in user1 group. Note that when Kmail is started as a "different" user1, a kdesu error message appears but Kmail runs OK. This might have been have due to a root owned instance in a previous but non-logged-on session. (I have since gotten rid of this.)
I agree here : kmail shouldn't mess with folder or files permissions. I tried to run kmail using a specific umask, but kmail disregard it totally for certain files. Reproduction : - $ umask 0002 - $ kmail - create a folder named "test" - look at the permissions for .test* - look at the permissions for the test folder and its subfolders Results for permissions : - "test" folder = 600 - .test.index = 600 - test/cur, test/new and test/tmp = 600 - all other files follow umask (.test.index.ids, .test.index.sorted and files in "cur", "new" and "tmp")
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.