[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Bug#45694: acknowledged by developer (kmail fails to update its folder index properly)
From:       V K <list0570 () paradise ! net ! nz>
Date:       2002-07-31 23:50:09
[Download RAW message or body]

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 Kuhlmann			is possibly list0570 with the domain in header
http://volker.orcon.net.nz/		Please do not CC list postings to me.


(Complete bug history is available at http://bugs.kde.org/db/45/45694.html)
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]