(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.4.1 (using KDE 3.0.1 ) Severity: normal Installed from: SuSE Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18-4GB OS/Compiler notes: kmail should check EACH TIME WHEN CLICKING ON A NEW FOLDER FROM THE LIST ON THE LEFT OR WHEN MOVING/COPYING MAILS TO A FOLDER whether that folder has changed and whether therefore kmail needs to update its folder index. I just lost a whole folder because the folder is written to by other programs. kmail's folder locking is pathetic i.e. non-existent. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 list0570@paradise.net.nz wrote: > kmail should check EACH TIME WHEN CLICKING ON A NEW FOLDER FROM THE > LIST ON THE LEFT OR WHEN MOVING/COPYING MAILS TO A FOLDER whether Why the fuck do you think you have to shout at us? > that folder has changed and whether therefore kmail needs to update > its folder index. I just lost a whole folder because the folder is > written to by other programs. kmail's folder locking is pathetic i.e. > non-existent. That's correct. Please read the corresponding FAQ (How to use procmail=20 with KMail). This is no bug but at most a wish and furthermore it's a duplicate.=20 Therefore I close it. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9PomHqUQWN/hplRsRArCDAJ9NAOMkbJYdoG+N6kraEVSu6nknVwCePD0c sussBfyS1NXK77mrba4x+C0=3D =3D1N5L -----END PGP SIGNATURE-----
kmail does not re-examine folders's size/time stamp/etc when it reads them or writes to them. Instead it relies on its own cached information. This information can be incorrect it's easy to prove - click on one of the folders on the left its contents are displayed on the right add another mail with cat >>folder click on the folder again kmail will not see the new email not even when clicking on another folder and then again on the first one. This is incorrect behaviour. It's dangerous. It's a bug but feel free to close the bug report. > > written to by other programs. kmail's folder locking is pathetic i.e. > > non-existent. > > That's correct. Please read the corresponding FAQ (How to use procmail=20 > with KMail). Have done so more than once. It requires me to specifiy all folders 1 by 1 which for >50 folders is at least tedious. Even if I put the effort in kmail forces me to specify a second file and then when I load one of the folders SWOOOOOOOOOOOOOSH the folder is suddenly empty and everything is in the second file. Excuse me? Do I specify that file as well then? Ad infinitum? The manual may say something about this topic but the kmail feature is completely useless. Net result is as I said kmail doesn't do folder locking. Most of my folders are safe though as kmail's (also de-facto) non-existing ability to access folders in sub-directories (before you mention the obvious yet it's in the manual but it requires at least 3 attempts to get working) can only be described as utterly braindead. I'd be interested in the rationale behind this though. Volker
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 25 July 2002 03:30 V K wrote: <snip> > This is incorrect behaviour. It's dangerous. It's a bug but feel > free to close the bug report. <snip> Please read what people write. He said it's duplicate. > Have done so more than once. It requires me to specifiy all folders > 1 by 1 which for >50 folders is at least tedious. Even if I put the > effort in kmail forces me to specify a second file and then when I > load one of the folders SWOOOOOOOOOOOOOSH the folder is suddenly > empty and everything is in the second file. Excuse me? Do I specify > that file as well then? Ad infinitum? The manual may say something > about this topic but the kmail feature is completely useless. Net > result is as I said kmail doesn't do folder locking. KMail assumes ownership of ~/Mail at least as long as it is running.=20 Point. If KMail doesn't fit your needs why do you insist on using it?=20 Most people that talk like you use another mailer... > Most of my folders are safe though as kmail's (also de-facto) > non-existing ability to access folders in sub-directories (before you > mention the obvious yet it's in the manual but it requires at least > 3 attempts to get working) can only be described as utterly > braindead. I'd be interested in the rationale behind this though. <snip> I'm not sure I'm with you here. Can netscape mail access folders in=20 subdirs not ending with .sbd? Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9QC+e3oWD+L2/6DgRAnX8AKCGqAhuo+y9PdFFWpDWhsoWVi2xGQCeJsuE DqnOvsHMIkuJYWBkAmp+Opk=3D =3DcLt7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 25 July 2002 03:30 V K wrote: > Most of my folders are safe though as kmail's (also de-facto) > non-existing ability to access folders in sub-directories (before you > mention the obvious yet it's in the manual but it requires at least > 3 attempts to get working) can only be described as utterly > braindead. I'd be interested in the rationale behind this though. The rationale behind all this i.e. no folder locking and the above is=20 that KMail wasn't designed to share the mail folder with other=20 programs. It's as simple as that. If KMail is the only program which=20 accesses the contents of ~/Mail then none of the above is necessary=20 resp. a problem. Today it's clear that it was a bad design decision to assume that KMail=20 is the only program which accesses ~/Mail. This will be fixed at some=20 time in the future. If you can't live with the current restrictions=20 then you can't use KMail until this is fixed. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9RbyGGnR+RTDgudgRAmVEAJ0SOqMNmqYvslo9j9zZ/O6rihshzQCgyOsr IUoqVhITB/s/R1fQJ3zHOZc=3D =3D73jG -----END PGP SIGNATURE-----
On Tuesday 30 July 2002 08:07 Ingo Klöcker wrote: > Today it's clear that it was a bad design decision to assume that > KMail is the only program which accesses ~/Mail. Ingo I strongly disagree. File locking of ~/Mail is the bad idea and should be discouraged. There's no standard for the locking mechanism which is dangerous and file locking doesn't prevent partially written mails from being written. These flaws in ~/Mail locking are why Maildir was developed. But my main problem with locking of ~/Mail is that it is a non-scalable design it makes it impossible to index the mbox files efficiently. Under the ~/Mail locking design external programs can not only append to mbox files but modify them randomly some programs do so without changing the file date. Thus the only way to handle mbox files under the ~/Mail locking design is to rescan them completely. Scalable mail clients do no support ~/Mail locking. Evolution Mozilla and KMail all keep index files and do not support ~/Mail locking. KMail is able to efficiently handle much larger folders than clients that depend on ~/Mail locking like pine and mutt. > This will be fixed > at some time in the future. Locking of mbox files in ~/Mail is a fundamentally flawed designed. It can't be fixed and still allow for efficient handling of large folders. KMail can be criticised for keeping mail in ~/Mail and not supporting file locking since locking of files in ~/Mail used to be something of a standard. But this criticism is weak as before KMail used ~/KMail and many users complained asking the KMail developers to use ~/Mail instead. Really the problem is with users who mistakenly assume KMail supports a broken design like ~/Mail locking. Unfortunately such an assumption might be stupid but it is also human and common. Instead of checking for reliance on ~/Mail locking (that is checking to see if an external program modifies mbox files in ~/Mail) and silently trying to work around this it would be much better if KMail checked and gave a strong visual warning to users that ~/Mail locking is not supported. Unfortunately we can't do this without upsetting NFS users. Because NFS is broken by design and triggers our checks for external programs modifying mbox files. I think the best thing is to check for mbox files being modifed by external programs and show a warning. This warning should indicate how to turn of mbox checking for NFS users. Don Sanders
On Tue 30 Jul 2002 18:26:12 NZST +1200 Don Sanders wrote: > On Tuesday 30 July 2002 08:07 Ingo Klöcker wrote: > > Today it's clear that it was a bad design decision to assume that > > KMail is the only program which accesses ~/Mail. > > Ingo I strongly disagree. Don I strongly disagree with you. > File locking of ~/Mail is the bad idea and should be discouraged. File locking is always a good idea. The alternative of stuffing sufficiently randomised filenames into a directory doesn't convince. Perhaps there's another alternative. Many programs can obviously cope with different locking standards that's no argument. Locking with e.g. procmail and mutt works extremely well. True that applications need to agree on locking standard(s) but that technique is commonly used in many places. To the contrary of your argument *not* locking is very dangerous. > These flaws in ~/Mail locking are why Maildir was developed. There may be flaws but that's not a good reason to do nothing. Besides one can argue about "flaws". "Some problems which can be solved" is more accurate. Maildir solves some problems and creates new difficulties. I am not the only one who finds it difficult to handle. In contrast I can run one grep on 5 mailboxes easily with mbox forget about doing that with maildir. Maildir's lack of subdirectories is a laugh and something I don't find acceptable. > But my main problem with locking of ~/Mail is that it is a > non-scalable design it makes it impossible to index the mbox files > efficiently. Under the ~/Mail locking design external programs can > not only append to mbox files but modify them randomly some programs > do so without changing the file date. Thus the only way to handle > mbox files under the ~/Mail locking design is to rescan them > completely. The indexing in kmail is broken. Before accessing any file it's size *and* time needs to be checked and the file needs to be recanned if necessary. I don't see any problem at all with rescanning certainly not with rescanning just one file. kmail seems to scan the whole big lot when it starts (in some cases anyway) which is neither fast nor necessary. Not rescanning is dangerous and can lead to data loss. If the choice is between data loss and rescanning a file your reasons about not rescanning go out the door. There is no problem with scalability. We're only talking mbox here. I never found the time it takes mutt to scan a folder when opening it to be any problem at all. If you really need to have 150MB in a mail folder either use maildir or put up with the time it takes to scan the file. Scan intelligently like mutt does and yes it works and I never lost anything there. In any case file locking of mbox files is mandatory and does not cause additional disadvantages other than sacn time. You could put an option "don't lock if you know no other app will access the file but lose data if some app does" option. Saying mbox doesn't scale as well isn't true. Access time is proprtional to size. "Bad scaling" is when time is more than proportional to size. Also any mbox file should be locked not just those under ~/Mail but I supppose that's arguable (e.g. locking will fail if it's on CD). An good mail client should also be able to just open an mbox file from anywhere including /tmp (if I restored some very old mail from CD I want to look at). Sorry Don but your arguments don't hold. "Not as fast" and "has more issues to solve but solutions are readily available by copy/paste from other GPL software" is no reason to not lock files. The locking problem has been solved. The reason it's not implemented appear to be rather of a political nature to me. > Scalable mail clients do no support ~/Mail locking. Evolution Mozilla > and KMail all keep index files and do not support ~/Mail locking. All these clients are tailored for the computer-illiterate user at the other end of a pop3. There's nothing wrong with that unless the literate person is ignored. The assumption that $MAILCLIENT is the only program writing under ~/Mail is seriously flawed. It's not with Unix tradition of having a system of parts interoperating with each other. It's ignoring procmail which is a very fine mail filter. And it's (indirectly) forcing a dependence on just one mail client via a dependence on filtering. I don't have a problem with kmail implementing its own filtering but I object to being forced to use it. Implementing the same filter rules in more than one place is not desirable. kmail does not interoperate with procmail neither do those not bothering about locking. Sure you could just say don't use kmail then but that's beside the point (all other GUI clients are the same wrt interoperability). I'd love to move up to a GUI client from text based ones but find that GUI ones are not an extension (in terms of features) to traditional ones. GUI clients simply can't do what text based clients are able to (ok pine might be different). > Really the problem is with users who mistakenly assume KMail supports > a broken design like ~/Mail locking. Unfortunately such an assumption Then kmail (and similar clients) is lacking in features. Of course for newbies the issue doesn't exist (no more than 5 mailboxes never uses grep fetchmail or procmail). I don't agree with your opinion Don that locking is a broken design. It can be made to work reliably proof is there. You are taking the lazy way out. Volker -- Volker Kuhlmannis possibly list0570 with the domain in header http://volker.orcon.net.nz/Please do not CC list postings to me.
On Tuesday 30 July 2002 17:49 V K wrote: > On Tue 30 Jul 2002 18:26:12 NZST +1200 Don Sanders wrote: > > On Tuesday 30 July 2002 08:07 Ingo Klöcker wrote: > > > Today it's clear that it was a bad design decision to assume > > > that KMail is the only program which accesses ~/Mail. > > > > Ingo I strongly disagree. > > Don I strongly disagree with you. > > > File locking of ~/Mail is the bad idea and should be discouraged. > > File locking is always a good idea. Not on NFS systems where it hangs. > The alternative of stuffing > sufficiently randomised filenames into a directory doesn't > convince. Perhaps there's another alternative. Many programs can > obviously cope with different locking standards that's no > argument. Locking with e.g. procmail and mutt works extremely well. > True that applications need to agree on locking standard(s) but > that technique is commonly used in many places. To the contrary of > your argument *not* locking is very dangerous. KMail considers its mail folder files private so that locking is unnecessary. Modifying KMail private files is the same as modifying the private files of any other application if you try it without knowing what you are doing you are asking for trouble. > > These flaws in ~/Mail locking are why Maildir was developed. > > There may be flaws but that's not a good reason to do nothing. > Besides one can argue about "flaws". "Some problems which can be > solved" is more accurate. > > Maildir solves some problems and creates new difficulties. I am not > the only one who finds it difficult to handle. In contrast I can > run one grep on 5 mailboxes easily with mbox forget about doing > that with maildir. Maildir's lack of subdirectories is a laugh and > something I don't find acceptable. Maildir can be used with subdirectories e.g. in KMail. A graphical interface or shell script can be used for searching. > > But my main problem with locking of ~/Mail is that it is a > > non-scalable design it makes it impossible to index the mbox > > files efficiently. Under the ~/Mail locking design external > > programs can not only append to mbox files but modify them > > randomly some programs do so without changing the file date. > > Thus the only way to handle mbox files under the ~/Mail locking > > design is to rescan them completely. > > The indexing in kmail is broken. Before accessing any file it's > size *and* time needs to be checked and the file needs to be > recanned if necessary. When reading a large file it would be massivley inefficient to check file size and date before every fread. > I don't see any problem at all with > rescanning certainly not with rescanning just one file. kmail > seems to scan the whole big lot when it starts (in some cases > anyway) which is neither fast nor necessary. If KMail rescans your mbox files then it indicates something is wrong like the files have been modified by an external program. > Not rescanning is > dangerous and can lead to data loss. If the choice is between data > loss and rescanning a file your reasons about not rescanning go out > the door. Hitting your computer with a large hammer is also dangerous and can lead to data loss. Like corrupting files KMail uses I suggest you do not do it. > There is no problem with scalability. We're only talking mbox here. > I never found the time it takes mutt to scan a folder when opening > it to be any problem at all. I've found mutt to be extremely slow and resource intensive for large mbox files. > If you really need to have 150MB in a > mail folder either use maildir or put up with the time it takes to > scan the file. No I will not if I like I will use a mail client that can handle large mbox files efficiently. >Scan intelligently like mutt does and yes it works > and I never lost anything there. It doesn't really work if you grow old and die while you are waiting for the operation to complete. I find the performance of mutt on large folders to be unacceptable slow. > In any case file locking of mbox > files is mandatory and does not cause additional disadvantages > other than sacn time. You could put an option "don't lock if you > know no other app will access the file but lose data if some app > does" option. A feature request to add optional support for ~/Mail locking is more sensible but I won't be implementing it. > Saying mbox doesn't scale as well isn't true. Access time is > proprtional to size. "Bad scaling" is when time is more than > proportional to size. I don't say mbox doesn't scale well. I say ~/Mail locking doesn't scale. I say this because ~/Mail locking results in unacceptably slow performance for large but realistically sized mail folders. > Also any mbox file should be locked not just those under ~/Mail > but I supppose that's arguable (e.g. locking will fail if it's on > CD). An good mail client should also be able to just open an mbox > file from anywhere including /tmp (if I restored some very old > mail from CD I want to look at). > > Sorry Don but your arguments don't hold. "Not as fast" and "has > more issues to solve but solutions are readily available by > copy/paste from other GPL software" is no reason to not lock files. You are misquoting me I did not write that. > The locking problem has been solved. The reason it's not > implemented appear to be rather of a political nature to me. Politics relates to government. If you want to believe there's some kind of government conspiracy preventing KMail from supporting ~/Mail locking then I doubt I will be able to persuade you otherwise. > > Scalable mail clients do no support ~/Mail locking. Evolution > > Mozilla and KMail all keep index files and do not support ~/Mail > > locking. > > All these clients are tailored for the computer-illiterate user at > the other end of a pop3. There's nothing wrong with that unless > the literate person is ignored. > > The assumption that $MAILCLIENT is the only program writing under > ~/Mail is seriously flawed. It's not with Unix tradition of having > a system of parts interoperating with each other. True it breaks with Unix tradition this is a valid criticism. > It's ignoring > procmail which is a very fine mail filter. False procmail is supported see the FAQ I don't buy arguments that the procedure in that FAQ is too difficult to follow. > And it's (indirectly) > forcing a dependence on just one mail client True. > via a dependence on > filtering. False the dependency is enforced due to incompatible index file formats. But because KMail supports conventional file formats for mail it is not that hard to switch from one mail client to another. > I don't have a problem with kmail implementing its own > filtering but I object to being forced to use it. Implementing the > same filter rules in more than one place is not desirable. kmail > does not interoperate with procmail neither do those not bothering > about locking. Procmail support is covered in the FAQ. > Sure you could just say don't use kmail then but that's beside the > point (all other GUI clients are the same wrt interoperability). > I'd love to move up to a GUI client from text based ones but find > that GUI ones are not an extension (in terms of features) to > traditional ones. GUI clients simply can't do what text based > clients are able to (ok pine might be different). I think Balsa doesn't use index files you could try that. > > Really the problem is with users who mistakenly assume KMail > > supports a broken design like ~/Mail locking. Unfortunately such > > an assumption > > Then kmail (and similar clients) is lacking in features. Of course > for newbies the issue doesn't exist (no more than 5 mailboxes > never uses grep fetchmail or procmail). > > I don't agree with your opinion Don that locking is a broken > design. It can be made to work reliably proof is there. You are > taking the lazy way out. There is no proof conventiional ~/Mail locking cannot be supported efficiently. Show me a mail client that can handle large mbox files efficiently and supports ~/Mail locking. I've tried both mutt and pine and found neither can. The main place they fail is when a mail is deleted and the user opens a new folder. Don.
On Tue 30 Jul 2002 21:30:00 NZST +1200 Don Sanders wrote: > > File locking is always a good idea. > > Not on NFS systems where it hangs. It doesn't hang on all. A turn-off feature would solve that easily. > KMail considers its mail folder files private so that locking is > unnecessary. The files are not kmail's they're mine but I'm sure you'll disagree. > > Maildir solves some problems and creates new difficulties. I am not > > the only one who finds it difficult to handle. In contrast I can > > run one grep on 5 mailboxes easily with mbox forget about doing > > that with maildir. Maildir's lack of subdirectories is a laugh and > > something I don't find acceptable. > > Maildir can be used with subdirectories e.g. in KMail. A graphical Well I have several subdirectories in ~/Mail/ and kmail doesn't show *any* of them in the folder list under ~/Mail. Yes I have read the manual and that symlink-diddling can best be described as cumbersome. Kmail doesn't usefully support subdirs if you're saying otherwise you're having me on. (I did say this in a previous mail already?) Worse the instructions in the manual don't work. It says: "If you want to add a whole remote mail directory use ln -s /somewhere/Mail/.remotedir.directory ~/Mail/.mymailboxfile.directory." but doing it does absolutely nothing. It also requires touch ~/Mail/mymailboxfile The last bit is what makes ln -s existingdirunderMail ~/Mail/.existingdirunderMail.directory a pain and impossible. > interface or shell script can be used for searching. Perhaps true. Grep is easier and doesn't require time to get going. > When reading a large file it would be massivley inefficient to check > file size and date before every fread. Every *write* only I see that mutt does it so it's not really a problem I have not noticed any delays so far. > If KMail rescans your mbox files then it indicates something is wrong > like the files have been modified by an external program. Which is nothing wrong but we had that before. > Hitting your computer with a large hammer is also dangerous and can > lead to data loss. Like corrupting files KMail uses I suggest you do > not do it. This is a bit silly. > I've found mutt to be extremely slow and resource intensive for large > mbox files. Then our experiences differ considerably. > No I will not if I like I will use a mail client that can handle > large mbox files efficiently. I am looking for one which handles mbox files at any speed and *with* interaction with procmail. > It doesn't really work if you grow old and die while you are waiting > for the operation to complete. I find the performance of mutt on > large folders to be unacceptable slow. Let's disagree. > A feature request to add optional support for ~/Mail locking is more > sensible but I won't be implementing it. Fair enough to both. > I don't say mbox doesn't scale well. I say ~/Mail locking doesn't > scale. It's the same in practice. > I say this because ~/Mail locking results in unacceptably slow > performance for large but realistically sized mail folders. I disagree sorry. > > Sorry Don but your arguments don't hold. "Not as fast" and "has > > more issues to solve but solutions are readily available by > > copy/paste from other GPL software" is no reason to not lock files. > > You are misquoting me I did not write that. Wasn't meant to be a quote of anyone the marks delimit the phrases. And what you're saying boils down to those phrases - you object to locking because it's too slow for you. > If you want to believe there's some kind of government conspiracy > preventing KMail from supporting ~/Mail locking then I doubt I will > be able to persuade you otherwise. Let's not get too silly. Policies are commonly used in software development - that means there's politics :) > > The assumption that $MAILCLIENT is the only program writing under > > ~/Mail is seriously flawed. It's not with Unix tradition of having > > a system of parts interoperating with each other. > > True it breaks with Unix tradition this is a valid criticism. I don't have a problem at all with kmail not locking mbox folders as long as it's optional... > False procmail is supported see the FAQ I don't buy arguments that > the procedure in that FAQ is too difficult to follow. I had said in one of my first posts that this feature is useless. Kmail is unable to operate on folders procmail delivers to. If I try kmail will immediately empty out the whole folder and stash it away in some other place I am forced to specify. Why do you think I have procmail deliver to that folder in the first place? Perhaps because I want the mail to be there? Besides doing this for several dozen folders is not what I call user-friendly (even if it did achieve the purpose which it doesn't). The bottom line is kmail does not usefully work with procmail which is the main reason I can only read about 5% of mail with kmail. > > And it's (indirectly) > > forcing a dependence on just one mail client > > True. Not acceptable. kmail doesn't work via dialup when I'm not at home. Falling back on something like mutt in that case must remain a possibility. > formats. But because KMail supports conventional file formats for > mail it is not that hard to switch from one mail client to another. As long as they work with procmail. > Procmail support is covered in the FAQ. See above. And please stop pointing to the FAQ when it comes to procmail. The only way to make it work is useless. > Show me a mail client that can handle large mbox files efficiently and > supports ~/Mail locking. I've tried both mutt and pine and found > neither can. The main place they fail is when a mail is deleted and > the user opens a new folder. I haven't had trouble with mutt yet. Let me rephrase that its configuration is taking far too much time but it does the important jobs. It doesn't do well with supporting different of what kmail calls identities. That's one of the real pluses of kmail. Others are it's neat integration into the desktop and its pleasing look and feel. Volker -- Volker Kuhlmannis possibly list0570 with the domain in header http://volker.orcon.net.nz/Please do not CC list postings to me.
On Thursday 01 August 2002 09:50 V K wrote: > On Tue 30 Jul 2002 21:30:00 NZST +1200 Don Sanders wrote: > > > File locking is always a good idea. > > > > Not on NFS systems where it hangs. > > It doesn't hang on all. A turn-off feature would solve that easily. Well if you have a reliable solution for determining which systems locking hangs on please send in a patch and I'll gladly apply it. I don't want to add a lock mbox folders in ~/Mail option as I feel that will disguise rather than solve the problem. Basically I don't want to add more options. If you want to enable locking for mbox files in ~/Mail simply modify KMFolderMbox::KMFolderMbox in kmfoldermbox.cpp and change "mLockType = None;" to your preferred locking type (FCNTL procmail_lockfile mutt_dotlock or muttdotlock_priviledge). IMO FCNTL is by far the best if your system supports it. I would like to enable FCNTL by default but I also don't want to upset NFS users. > > KMail considers its mail folder files private so that locking is > > unnecessary. > > The files are not kmail's they're mine but I'm sure you'll > disagree. The mbox folders are like configuration files etc if you modify them without knowing what you are doing then you can corrupt them and cause data loss. > > > Maildir solves some problems and creates new difficulties. I am > > > not the only one who finds it difficult to handle. In contrast > > > I can run one grep on 5 mailboxes easily with mbox forget > > > about doing that with maildir. Maildir's lack of subdirectories > > > is a laugh and something I don't find acceptable. > > > > Maildir can be used with subdirectories e.g. in KMail. A > > graphical > > Well I have several subdirectories in ~/Mail/ and kmail doesn't > show *any* of them in the folder list under ~/Mail. Yes I have read > the manual and that symlink-diddling can best be described as > cumbersome. Kmail doesn't usefully support subdirs if you're > saying otherwise you're having me on. (I did say this in a previous > mail already?) KMail supports its own format for subfolders. Supporting the formats of other mail clients may be a nice feature I would consider a patch. > Worse the instructions in the manual don't work. It says: "If you > want to add a whole remote mail directory use ln -s > /somewhere/Mail/.remotedir.directory > ~/Mail/.mymailboxfile.directory." but doing it does absolutely > nothing. It also requires touch ~/Mail/mymailboxfile The website faq is correct http://kmail.kde.org/manual/faq.html states "If you want to add a whole remote mail directory use ln -s /somewhere/Mail ~/Mail/.remotedir.directory. For that case you also need to create a new empty folder named remotedir with KMail." > The last bit is what makes ln -s existingdirunderMail > ~/Mail/.existingdirunderMail.directory a pain and impossible. Possibly It's not supported because this design for subfolders is a stupid design. If I call a mail directory foo then I can't create an mbox file called foo in the same directory hence I can't put mail in folder foo only in subfolders of foo. Unless you specially name an mbox somewhere that corresponds to directory foo but then you have created something equivalent to the current format. Basically the design you are asking to be supported sucks because if a folder has child folders you can only put mail in the child folders and not in the parent folder. Nevertheless I would consider supporting it if a patch was submitted. I definitely don't think KMail should create folders in such a format. > > interface or shell script can be used for searching. > > Perhaps true. Grep is easier and doesn't require time to get going. For many people grep is harder to use than a GUI. I also don't buy your argument that grep is too difficult to use on Maildir. > > When reading a large file it would be massivley inefficient to > > check file size and date before every fread. > > Every *write* only I see that mutt does it so it's not really a > problem I have not noticed any delays so far. You wrote "access" in the paragraph you have deleted. access and write are very different things. Anyway as I have repeatedly stated just because a files date and size has remained constant doesn't imply the file hasn't been modified. mutt for some reason forces the date of a file to remain the same even after modifying the file. So it's possible both the date and size of a file may be constant even after mutt has modified the contents of the file. Checking file data and size and regenerating the index wouldn't allowing sharing of mbox files it would just make it much more difficult to reproduce and understand mail losing behavior. > > If KMail rescans your mbox files then it indicates something is > > wrong like the files have been modified by an external program. > > Which is nothing wrong but we had that before. It indicates something is wrong because it indicates an external program may have corrupted KMail files. > > Hitting your computer with a large hammer is also dangerous and > > can lead to data loss. Like corrupting files KMail uses I suggest > > you do not do it. > > This is a bit silly. What I am saying is if something causes you pain then maybe you shouldn't do it. If corrupting files is causing you data loss then I suggest you stop corrupting files. > > I've found mutt to be extremely slow and resource intensive for > > large mbox files. > > Then our experiences differ considerably. Well here's my experience take a typical mbox file with about 10000 messages (40MB) in it. mutt takes about 4 seconds to open this file while KMail takes well under a second. I'm assumming KMail has already generated its index file here but this should always be the case for normal operation of KMail. Deleting some mails in this mbox folder and changing to a different mbox file took 18 seconds under mutt and about 4 seconds under KMail. Here KMail is definitely too slow and I do plan to optimize this further but mutt is unacceptably slow. Perhaps the slow performance of mutt is acceptable to you but it's not acceptable to me it's not acceptable to many KMail users and I don't plan to make KMail slower to add support for a meritless feature. > > No I will not if I like I will use a mail client that can > > handle large mbox files efficiently. > > I am looking for one which handles mbox files at any speed and > *with* interaction with procmail. > > > It doesn't really work if you grow old and die while you are > > waiting for the operation to complete. I find the performance of > > mutt on large folders to be unacceptable slow. > > Let's disagree. > > > A feature request to add optional support for ~/Mail locking is > > more sensible but I won't be implementing it. > > Fair enough to both. > > > I don't say mbox doesn't scale well. I say ~/Mail locking doesn't > > scale. > > It's the same in practice. It's not the same because mbox can be handled efficiently but a system that requires completely rescanning mbox files everytime they are opened cannot be efficient. > > I say this because ~/Mail locking results in unacceptably slow > > performance for large but realistically sized mail folders. > > I disagree sorry. I have made empirical tests on several occasions and found mutt to be much slower than KMail. I give example results above. > > > Sorry Don but your arguments don't hold. "Not as fast" and "has > > > more issues to solve but solutions are readily available by > > > copy/paste from other GPL software" is no reason to not lock > > > files. > > > > You are misquoting me I did not write that. > > Wasn't meant to be a quote of anyone the marks delimit the > phrases. And what you're saying boils down to those phrases - you > object to locking because it's too slow for you. Quote marks indicate quotation. If you are not quoting someone then I suggest you do not use quote marks. KMail is currently too slow for me and I work to make it faster I definitely don't want to make it as slow as clients that rely on convnetional ~/Mail locking that would be a step backwards. > > > The assumption that $MAILCLIENT is the only program writing > > > under ~/Mail is seriously flawed. It's not with Unix tradition > > > of having a system of parts interoperating with each other. > > > > True it breaks with Unix tradition this is a valid criticism. > > I don't have a problem at all with kmail not locking mbox folders > as long as it's optional... It is optional in the sense you can change one line of source as I have described above. > > False procmail is supported see the FAQ I don't buy arguments > > that the procedure in that FAQ is too difficult to follow. > > I had said in one of my first posts that this feature is useless. > Kmail is unable to operate on folders procmail delivers to. If I > try kmail will immediately empty out the whole folder and stash it > away in some other place I am forced to specify. Why do you think I > have procmail deliver to that folder in the first place? Perhaps > because I want the mail to be there? Besides doing this for > several dozen folders is not what I call user-friendly (even if it > did achieve the purpose which it doesn't). The bottom line is > kmail does not usefully work with procmail which is the main > reason I can only read about 5% of mail with kmail. It is true we do not support the inefficient non-scalable way of using procmail that you insist on using. We do support an efficient scalable way of using procmail. > > > And it's (indirectly) > > > forcing a dependence on just one mail client > > > > True. > > Not acceptable. kmail doesn't work via dialup when I'm not at home. > Falling back on something like mutt in that case must remain a > possibility. This is a legitimate and serious problem. IMAP potentially offers a solution but has problems of it's own. A text based interface to KMail is another solution this might not be too hard to do using dcop. > > formats. But because KMail supports conventional file formats for > > mail it is not that hard to switch from one mail client to > > another. > > As long as they work with procmail. Procmail is irrelevant here. You can switch to another mail client easily as long as it supports mbox or maildir. > > Procmail support is covered in the FAQ. > > See above. And please stop pointing to the FAQ when it comes to > procmail. The only way to make it work is useless. I disagree. The method outlined in the FAQ is only useless if you insist on handling mail in an inefficient way. > > Show me a mail client that can handle large mbox files > > efficiently and supports ~/Mail locking. I've tried both mutt and > > pine and found neither can. The main place they fail is when a > > mail is deleted and the user opens a new folder. > > I haven't had trouble with mutt yet. Let me rephrase that its > configuration is taking far too much time but it does the > important jobs. It doesn't do well with supporting different of > what kmail calls identities. That's one of the real pluses of > kmail. Others are it's neat integration into the desktop and its > pleasing look and feel. I've had trouble with mutt because it cannot efficiently handle large folders. Really 10000 mails is not even large it's moderately sized. We do handle moderately sized folders ok better than any other *nix client I've examined but there's still a lot of room for improvement. Supporting conventionay ~/Mail locking would retard the progress we have made and prevent further improvement. Don.