Kmail has recently crashed on me, and after I restarted it, some of my disconnected imap folders are reported as read-only. My setup is the following: on the mail server itself, I use a .procmail file to sort mail into several folders. I have then kmail running on my laptop, using the dimap protocol, to download these folders. I do not understand what "read-only" means in this context. On the server itself, all files are readable by me (and some of the folders are still read-write, so it doesn't appear to be a general problem with the directory itself). Locally, I have done a chmod -R u+w ~/.kde/share/apps/kmail, so there as well all files are writable. Any hint as to how to fix that ? Thanks in advance regards Emmanuel
Emmanuel Briot wrote:
Kmail has recently crashed on me, and after I restarted it, some of my disconnected imap folders are reported as read-only. My setup is the following: on the mail server itself, I use a .procmail file to sort mail into several folders. I have then kmail running on my laptop, using the dimap protocol, to download these folders.
I do not understand what "read-only" means in this context. On the server itself, all files are readable by me (and some of the folders are still read-write, so it doesn't appear to be a general problem with the directory itself). Locally, I have done a chmod -R u+w ~/.kde/share/apps/kmail, so there as well all files are writable.
Usually a service marks files as read-only when another process has already claimed read-write access for these files. Look for imap daemons that are still running for your old kmail process and block write access to your folders for your current imap process. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
On Tuesday 31 January 2006 17:12, Sandy Drobic wrote:
Usually a service marks files as read-only when another process has already claimed read-write access for these files. Look for imap daemons that are still running for your old kmail process and block write access to your folders for your current imap process.
Interesting experiment. There is no such process running on the server. I have just tried using mutt on one of the read-only folders: mutt -f imaps://host/Mail/folder and the folder wasn't in read-only mode... This looks like a client problem. I have reboot my laptop, but that hasn't helped. Thanks! Emmanuel
Interesting experiment. There is no such process running on the server. I have just tried using mutt on one of the read-only folders: mutt -f imaps://host/Mail/folder and the folder wasn't in read-only mode...
This looks like a client problem. I have reboot my laptop, but that hasn't helped.
[replying to myself, sorry] Part of the mystery solved: we had NFS locks remaining on the server, and after doing whatever magic was necessary, mutt now behaves correctly (and I can delete messages, which I in fact couldn't do in the experiment above). But Kmail still insists on thinking the folders are read-only Emmanuel
Emmanuel Briot wrote:
Interesting experiment. There is no such process running on the server. I have just tried using mutt on one of the read-only folders: mutt -f imaps://host/Mail/folder and the folder wasn't in read-only mode...
This looks like a client problem. I have reboot my laptop, but that hasn't helped.
[replying to myself, sorry] Part of the mystery solved: we had NFS locks remaining on the server, and after doing whatever magic was necessary, mutt now behaves correctly (and I can delete messages, which I in fact couldn't do in the experiment above).
But Kmail still insists on thinking the folders are read-only
I don't use Kmail but it could be a lock file that has been left by the previous session of Kmail. It's worth a search. On our Samba server I use "lsof /path/to/file" to find which process has the problem file locked. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Op dinsdag 31 januari 2006 19:19, schreef Sandy Drobic:
[replying to myself, sorry] Part of the mystery solved: we had NFS locks remaining on the server, and after doing whatever magic was necessary, mutt now behaves correctly (and I can delete messages, which I in fact couldn't do in the experiment above).
But Kmail still insists on thinking the folders are read-only
I don't use Kmail but it could be a lock file that has been left by the previous session of Kmail. It's worth a search. On our Samba server I use "lsof /path/to/file" to find which process has the problem file locked.
Go to your kmailrc file in $HOME/.kde/share/config Look up the folder with your ReadOnly problem, most likely the ReadOnly flag has been set to true, change it false.. -- Richard Bos Without a home the journey is endless
On Tuesday 31 January 2006 20:55, Richard Bos wrote:
Go to your kmailrc file in $HOME/.kde/share/config Look up the folder with your ReadOnly problem, most likely the ReadOnly flag has been set to true, change it false..
You are my new hero, that worked :-) A summary for the archives: It sometimes happens after a crash that kmail leaves some folders as read-only. In my case, I think what happened is the following: - kmail crashed, and cut the imap connection. That terminates the imap server, which left some locks (NFS locks) on the files on the server - When restarted, kmail detected the read-only status of the remote files, and set its config file accordingly. - Even after fixing the NFS lock issue on the server, kmail had its config set to read-only. The only solution is to kill kmail, edit the file ~/.kde/share/config/kmailrc and replace all ReadOnly=true lines with ReadOnly=false, and then restart kmail. Thanks to all who helped Emmanuel
Op dinsdag 31 januari 2006 23:28, schreef Emmanuel Briot:
It sometimes happens after a crash that kmail leaves some folders as read-only. In my case, I think what happened is the following: - kmail crashed, and cut the imap connection. That terminates the imap server, which left some locks (NFS locks) on the files on the server
Won't it be that kmail sets the flag to ReadOnly during e.g. compressing the folder operation. This happens at exit. Than when it crashes or whaterver, the flag is not restored to ReadOnly=false and the problem is there. -- Richard Bos Without a home the journey is endless
participants (3)
-
Emmanuel Briot -
Richard Bos -
Sandy Drobic