Version: 1.5.1 (using KDE 3.1.1) Installed from: SuSE Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB When a new folder ~/Mail/newfolder (mbox format) is created, kmail can't access it. (The fact that kmail is extremely narrow-minded about what folders it likes to display and which therefore can be accessed doesn't help.) Creating the "folder" from within kmail fails with "file already exists".
Subject: New: new folders can't be accessed Did you create the folder while KMail was running? If yes, does the folder appear after a restart of KMail? Am Montag, 17. November 2003 09:39 schrieb list0570@paradise.net.nz: > When a new folder ~/Mail/newfolder (mbox format) is created, kmail can't > access it. (The fact that kmail is extremely narrow-minded about what > folders it likes to display and which therefore can be accessed doesn't > help.) Creating the "folder" from within kmail fails with "file already > exists".
Subject: Re: new folders can't be accessed > Did you create the folder while KMail was running? If yes, does the folder > appear after a restart of KMail? The mbox file was created while kmail was running. Restarting kmail makes the folder appear. Also, removing a folder while kmail is running doesn't make it disappear from kmail until kmail is quit. It is not the point however to keep on restarting kmail each time there is a folder change (which reminds me of "your mouse has moved - press enter to reboot for the change to take effect"). Note that with "restarting kmail" I mean 1) quit kmail, 2) delete all kmail index files, 3) start kmail. Step 2) is scripted and is required to deal with various other kmail shortcomings. Volker
Volker, there is no need to delete index files in order for kmail to notice changes to the filesystem such as new or deleted folders (created and deleted outside of kmail). A simple restart suffices. It would be nice to detect such things at runtime, possibly by monitoring the ~/Mail dir, but that is a feature request and not a bug. I am therefor changing the severity of this bug report to wishlist and changing the summary. I assume the "various other kmail shortcomings" you are talking about refer to #61384?
Subject: Re: Automatically detect folders created or deleted in ~/Mail while kmail is runnig Thanks you two for your replies! > Volker, there is no need to delete index files in order for kmail to > notice changes to the filesystem such as new or deleted folders > (created and deleted outside of kmail). A simple restart suffices. That would be nice if it was true, but my experience tells me otherwise. The reason I scripted deletion of kmail's index files was/is that restarting kmail was insufficient to make it display mbox file contents properly. This may of course have changed now. > It > would be nice to detect such things at runtime, possibly by monitoring > the ~/Mail dir, but that is a feature request and not a bug. I am > therefor changing the severity of this bug report to wishlist and > changing the summary. Ok. Likewise, not only ~/Mail should be checked, but the folder as well each time a folder is selected (comparing the time stamp on the mbox file with the index file can be easily done without taking much CPU), I keep on adding a msg to an mbox file and then finding that I have to restart kmail to get it to even find the new msg - somewhat frustrating. > I assume the "various other kmail shortcomings" you are talking about > refer to #61384? Yes, but also that restarting kmail wasn't (isn't?) sufficient to get things going, as mentioned above. Volker
Subject: Automatically detect folders created or deleted in ~/Mail while kmail is runnig Am Dienstag, 18. November 2003 07:34 schrieb list0570@paradise.net.nz: > Ok. Likewise, not only ~/Mail should be checked, but the folder as well > each time a folder is selected (comparing the time stamp on the mbox > file with the index file can be easily done without taking much CPU), I > keep on adding a msg to an mbox file and then finding that I have to > restart kmail to get it to even find the new msg - somewhat frustrating. I was afraid you'ld be doing that. It's mentioned in the FAQ that manipulating folder contents from external programs when KMail is running can result in message loss. You should read the appropriate sections to get an impression of your risk. As I understood, there are plans to change some internals in KMail to make such manipulations possible. But this is not an issue for KDE 3.2 but for the long term. Please, read the relevant sections in the KMail handbook and reconsider your approach to handle e-mails. Regards, Andreas
Subject: Re: Automatically detect folders created or deleted in ~/Mail while kmail is runnig On Tuesday 18 November 2003 07:34, list0570@paradise.net.nz wrote: > > Volker, there is no need to delete index files in order for kmail to > > notice changes to the filesystem such as new or deleted folders > > (created and deleted outside of kmail). A simple restart suffices. > > That would be nice if it was true, but my experience tells me > otherwise. The reason I scripted deletion of kmail's index files was/is > that restarting kmail was insufficient to make it display mbox file > contents properly. This may of course have changed now. [snip] > Yes, but also that restarting kmail wasn't (isn't?) sufficient to get > things going, as mentioned above. For the case of new folders or deleted folders a restart without deletion of indeces should suffice. Changes to the mbox files kmail has already created indeces for do require regeneration of the index files. That's indeed suboptimal but already covered by your other bug report. Till
Subject: Re: Automatically detect folders created or deleted in ~/Mail while kmail is runnig > It's mentioned in the FAQ that manipulating folder contents from external > programs when KMail is running can result in message loss. This may be the case, but it makes the application (kmail) not very useful; whoever had the idea that my and only my true and only mail client is the only one which can access mail boxes should get some talking-to. Interoperation with procmail is a must and that is not currently possible. I am not prepared to commit myself to only one email client, there isn't one which is nearly good enough for that ;) (And there are situations where a text-based client is required, but I don't want to use a text-based one all the time.) So far however I haven't lost anything, kmail's index may be out of date (and therefore the folder contents display), but it is well-behaved and doesn't e.g. truncate files after the last msg it knows of. This situation arises when I save a msg from mutt to one of kmail's mailboxes, kmail will regenerate the index *if* that mailbox is not the current one *and* a minimum number of seconds (10-15?) pass since kmail last accessed that folder. I do however only use kmail for half of the job and don't give it access to folders which are written to by procmail, and receive all my mail with mutt and save it before I let kmail lose on it. I've always been surprised at how many features mutt has which are completely lacking in modern GUI clients (e.g. a simple file->open dialog, or in general to view/read mail boxes anywhere on the filesystem). kmail's great for sending mail (which is where mutt is lacking), but receiving mails doesn't really work, because by and large it can't handle mbox files properly. mutt shows it can be done, and reliably so. Greetings, Volker
Nothing has changed with kmail 1.6.2. kmail doesn't notice if a folder has changed even when restarting it. Either way, kmail being the only software having access to the folders is unacceptable for too many reasons, deleting kamil's index files remains necessary. A really good workaround would be 61384, which is desirable anyway.
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.