Re: serious bug. Evolution and Microsoft mentality.
On Sat, Jan 12, 2002 at 01:12:37PM +1100, Steve Kowalik wrote: At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Congratulations, you get today's Most Useless Use Of cat award. Plague, and LART will be forthcoming. If you're going to be a pedant, so am I. Firstly, your quoting style is wrong wrong wrong. Let me show you: BAD - on bar, foo wrote: don't fuck with me bitch i'll send the boys over, shithead GOOD - on baz, bar wrote: let's all sit around the fire and sing lesbian seagulls i love you man You see the difference? You don't leave a on the line trailing the quotation. That's just bad form. Also, wrt, Plague, and LART will be forthcoming: you're either missing a comma, or you've put an extra in. Should be either, Plague and LART will be forthcoming, or, preferably: Plague, and LART, will be forthcoming. But wait! Still more errors! You really mean, are forthcoming, not will be forthcoming, right? I hope so. -- Daniel Stone[EMAIL PROTECTED] bod subtle? bod and Overfiend in the same sentence? pgpeZ4UVRAScm.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Sat 12 Jan 2002, Daniel Stone wrote: On Sat, Jan 12, 2002 at 01:12:37PM +1100, Steve Kowalik wrote: At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Congratulations, you get today's Most Useless Use Of cat award. Plague, and LART will be forthcoming. If you're going to be a pedant, so am I. Of course, Steve *is* right. cat Mail/lists/* | cat /var/spool/mail/rob The first cat up to and including the pipe is totally useless, the way it's written. Of course, Rob probably meant a after the second cat, in which case the pipe and the second cat is superfluous. Paul Slootman
Re: serious bug. Evolution and Microsoft mentality.
On Sat, Jan 12, 2002 at 12:24:11PM +0100, Paul Slootman wrote: On Sat 12 Jan 2002, Daniel Stone wrote: On Sat, Jan 12, 2002 at 01:12:37PM +1100, Steve Kowalik wrote: At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Congratulations, you get today's Most Useless Use Of cat award. Plague, and LART will be forthcoming. If you're going to be a pedant, so am I. Of course, Steve *is* right. Yeah, I'm not arguing that, but he has a habit of making stupid mistakes when being a pedant. *shrug*. -- Daniel Stone[EMAIL PROTECTED] Nuke can NE1 help me aim nuclear weaponz? /MSG ME!! pgp2drp6NuiCR.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
The problem with spelling/grammar flames is they always blow up in your face. On Sat, Jan 12, 2002 at 08:06:17PM +1100, Daniel Stone wrote: Also, wrt, Plague, and LART will be forthcoming: you're either missing ^ This comma is completely out of place. Branden, you reading? We need some serious flaming here. Go sick. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
realpath c (was Re: serious bug. Evolution and Microsoft mentality.)
Richard Kettlewell writes:
Jonathan Walther [EMAIL PROTECTED] writes:
[...]
+
+ /* follow any symlinks to the mailbox */
+ memset(folder_path, 0, sizeof folder_path);
+ if (lstat (lf-folder_path, st) != -1 S_ISLNK (st.st_mode)
+ realpath (lf-folder_path, folder_path) != NULL) {
+ g_free (lf-folder_path);
+ lf-folder_path = g_strdup (folder_path);
+ }
This code silently breaks with very long filenames. As such it can
hardly be considered a correct patch!
Of course the underlying problem is that realpath() has a ridiculously
broken interface: it insists you supply a big-enough buffer, instead
of taking an argument that indicates how big a buffer you actually
have.
Even adding the argument would still leave a poor interface though:
some systems simply don't have a sensible upper bound on path name
size, so you'd have to repeatedly call it with ever-larger buffers,
potentially invoking multiple file system accesses each time.
Rather than just whine about this, and other similarly broken pathname
manipulation functions, I've written some new versions. You can find
an overview and the (LGPL) source code at:
http://www.greenend.org.uk/rjk/2002/01/pathfns.html
I'd be interested in any comments anyone has, either on the interface
or the implementation.
ttfn/rjk
Re: serious bug. Evolution and Microsoft mentality.
I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Then just check your mail and using the filters setup in evolution to filter it in the boxes again. Maybe not the best way, but i didnt lose any mail. -- Rob 'robster' Bradford Chief Editor/Lead developer DebianPlanet.org
Re: serious bug. Evolution and Microsoft mentality.
At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Congratulations, you get today's Most Useless Use Of cat award. Plague, and LART will be forthcoming. -- Steve (Reading database ... 134867 files and directories currently installed.) pgp1fyynSCxF8.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 11:49:59PM -0600, Adam Majer wrote: IMHO, it is not evil to append to the headers of the message. Every MTA does that. But if you delete stuff of alter the actual message, then it is evil.. I agree. But that is what Evolution does. This bug isn't planned to be fixed for a while as it involves the developers having to rethink their design. It seems they've already rejected the idea of rendering QP on the fly and leaving the internal data sacrosanct. Jonathan pgpBhR8vr9zvi.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, 9 Jan 2002, Mark Brown wrote: On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. I have yet to find out how to be able to see my inbox as well as all its subfolders (that's how it's set up on cyrus) from home. MUAs that don't interoperate happily with both could probably be considered buggy no ... - the main problem is likely to be namespacing and there's standard ways for the server to inform the client about the namespaces it uses. ... yes, the problem is namespacing and that allthough there's a standard it seems that either client (pine) or server cyrus 1.5.x from debian seem to be unable to get things straight between them. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: serious bug. Evolution and Microsoft mentality.
Tomas Pospisek's Mail Lists wrote: On Wed, 9 Jan 2002, Mark Brown wrote: On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. I have yet to find out how to be able to see my inbox as well as all its subfolders (that's how it's set up on cyrus) from home. I am not sure if uw-imap supports anything else but mbox format by default and with mbox you cannot have folders that contain message and subfolders (it's one or another). so there's no such thing as inbox and its subfolders. if you're using maildir and it doesn't work properly then I don't know, haven't tried uw-imap with maildir... erik
Re: serious bug. Evolution and Microsoft mentality.
On Thu, Jan 10, 2002 at 12:59:34PM +0100, Tomas Pospisek's Mail Lists wrote: On Wed, 9 Jan 2002, Mark Brown wrote: Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. I have yet to find out how to be able to see my inbox as well as all its subfolders (that's how it's set up on cyrus) from home. kmail and mutt both play happily with both the Courier and UW IMAP servers. - the main problem is likely to be namespacing and there's standard ways for the server to inform the client about the namespaces it uses. ... yes, the problem is namespacing and that allthough there's a standard it seems that either client (pine) or server cyrus 1.5.x from debian seem to be unable to get things straight between them. That's quite probably Pine being crap. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgphArKaQWIhj.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Thu, 10 Jan 2002, Erik Steffl wrote: Tomas Pospisek's Mail Lists wrote: On Wed, 9 Jan 2002, Mark Brown wrote: On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. I have yet to find out how to be able to see my inbox as well as all its subfolders (that's how it's set up on cyrus) from home. I am not sure if uw-imap supports anything else but mbox format by ^^^ Um a bit further down in my original posting I wrote: * ... yes, the problem is namespacing and that allthough there's a * standard it seems that either client (pine) or server cyrus 1.5.x from ^ * debian seem to be unable to get things straight between them. default and with mbox you cannot have folders that contain message and subfolders (it's one or another). so there's no such thing as inbox and its subfolders. if you're using maildir and it doesn't work properly then I don't know, haven't tried uw-imap with maildir... for cyrus INBOX seems to be the root directory. Incoming mail ends up in INBOX. Subdirs are created within INBOX. It might be that I didn't get cyrus the config right but AFAIK it's the default setup. But IMHO one should not be required to dig RFCs in depth to be able to use a mailclient. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: serious bug. Evolution and Microsoft mentality.
On Thu, 10 Jan 2002, Mark Brown wrote: On Thu, Jan 10, 2002 at 12:59:34PM +0100, Tomas Pospisek's Mail Lists wrote: On Wed, 9 Jan 2002, Mark Brown wrote: Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. I have yet to find out how to be able to see my inbox as well as all its subfolders (that's how it's set up on cyrus) from home. kmail and mutt both play happily with both the Courier and UW IMAP servers. I'm talking about cyrus. - the main problem is likely to be namespacing and there's standard ways for the server to inform the client about the namespaces it uses. ... yes, the problem is namespacing and that allthough there's a standard it seems that either client (pine) or server cyrus 1.5.x from debian seem to be unable to get things straight between them. That's quite probably Pine being crap. So following your logic IMP (which is using php-imap for imap access) is in that case crap as well, since it has similar problems (and all the other PHP apps that are using current php-imap as well). *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: serious bug. Evolution and Microsoft mentality.
On Thu, Jan 10, 2002 at 02:30:15PM +0100, Tomas Pospisek's Mail Lists wrote: On Thu, 10 Jan 2002, Mark Brown wrote: kmail and mutt both play happily with both the Courier and UW IMAP servers. I'm talking about cyrus. A while back it was more like IMAP is crap and barely interoperable - nothing except UW IMAP with Pine works out of the box. That's not quite the same thing. ... yes, the problem is namespacing and that allthough there's a standard it seems that either client (pine) or server cyrus 1.5.x from debian seem to be unable to get things straight between them. That's quite probably Pine being crap. So following your logic IMP (which is using php-imap for imap access) is in that case crap as well, since it has similar problems (and all the other PHP apps that are using current php-imap as well). Let's just say they're handling the situation less well than Outlook's standard IMAP client (and indeed most other IMAP clients I've tried). You seem to be picking bad clients :-) . -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpcCIs4JtBo8.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
Actually the attached patch is the correct one. There is no need to
memset and you should use PATH_MAX rather than 4096.
Jeff
On Wed, 2002-01-09 at 23:36, Jonathan Walther wrote:
On Wed, Jan 09, 2002 at 07:38:43PM -0500, Jeffrey Stedfast wrote:
Oops, copy/paste-o when migrating the patch to the 1-0 code base.
Here is the correct patch for the 1.0.x branch. Hopefully the Debian
maintainer will apply it? I am creating an Evolution 1.0-5.1 package
on my system with the patch applied. I haven't seen so many signal 11's
in aeons.
Index: camel/providers/local/camel-local-folder.c
===
RCS file: /cvs/gnome/evolution/camel/providers/local/camel-local-folder.c,v
retrieving revision 1.22
diff -u -r1.22 camel-local-folder.c
--- evolution/camel/providers/local/camel-local-folder.c2001/10/28
05:10:55 1.22
+++ evolution/camel/providers/local/camel-local-folder.c2002/01/09
21:44:15
@@ -23,8 +23,9 @@
#include config.h
#endif
#include stdlib.h
+#include limits.h
#include sys/types.h
#include dirent.h
#include sys/stat.h
#include unistd.h
@@ -173,8 +174,9 @@
CamelFolder *folder;
const char *root_dir_path, *name;
struct stat st;
int forceindex;
+ char folder_path[4096];
folder = (CamelFolder *)lf;
name = strrchr(full_name, '/');
@@ -190,8 +192,16 @@
lf-base_path = g_strdup(root_dir_path);
lf-folder_path = g_strdup_printf(%s/%s, root_dir_path, full_name);
lf-summary_path = g_strdup_printf(%s/%s.ev-summary, root_dir_path,
full_name);
lf-index_path = g_strdup_printf(%s/%s.ibex, root_dir_path,
full_name);
+
+ /* follow any symlinks to the mailbox */
+ memset(folder_path, 0, sizeof folder_path);
+ if (lstat (lf-folder_path, st) != -1 S_ISLNK (st.st_mode)
+ realpath (lf-folder_path, folder_path) != NULL) {
+ g_free (lf-folder_path);
+ lf-folder_path = g_strdup (folder_path);
+ }
lf-changes = camel_folder_change_info_new();
/* if we have no index file, force it */
--
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
[EMAIL PROTECTED] - www.ximian.com
Index: ChangeLog
===
RCS file: /cvs/gnome/evolution/camel/ChangeLog,v
retrieving revision 1.1311.2.11
diff -u -r1.1311.2.11 ChangeLog
--- ChangeLog 2002/01/04 22:17:52 1.1311.2.11
+++ ChangeLog 2002/01/10 17:30:10
@@ -1,3 +1,11 @@
+2002-01-09 Jeffrey Stedfast [EMAIL PROTECTED]
+
+ * providers/local/camel-local-folder.c
+ (camel_local_folder_construct): If the mbox file is a symlink,
+ follow the symlink and get the One True Path so that we can
+ rewrite the mbox later without worrying about clobbering the
+ symlink.
+
2001-12-12 Jeffrey Stedfast [EMAIL PROTECTED]
* camel-folder-summary.c (content_info_load): Don't try setting a
Index: providers/local/camel-local-folder.c
===
RCS file: /cvs/gnome/evolution/camel/providers/local/camel-local-folder.c,v
retrieving revision 1.22
diff -u -r1.22 camel-local-folder.c
--- providers/local/camel-local-folder.c2001/10/28 05:10:55 1.22
+++ providers/local/camel-local-folder.c2002/01/10 17:30:10
@@ -24,6 +24,7 @@
#endif
#include stdlib.h
+#include limits.h
#include sys/types.h
#include dirent.h
#include sys/stat.h
@@ -172,6 +173,7 @@
CamelFolderInfo *fi;
CamelFolder *folder;
const char *root_dir_path, *name;
+ char folder_path[PATH_MAX];
struct stat st;
int forceindex;
@@ -191,7 +193,14 @@
lf-folder_path = g_strdup_printf(%s/%s, root_dir_path, full_name);
lf-summary_path = g_strdup_printf(%s/%s.ev-summary, root_dir_path,
full_name);
lf-index_path = g_strdup_printf(%s/%s.ibex, root_dir_path,
full_name);
-
+
+ /* follow any symlinks to the mailbox */
+ if (lstat (lf-folder_path, st) != -1 S_ISLNK (st.st_mode)
+ realpath (lf-folder_path, folder_path) != NULL) {
+ g_free (lf-folder_path);
+ lf-folder_path = g_strdup (folder_path);
+ }
+
lf-changes = camel_folder_change_info_new();
/* if we have no index file, force it */
Re: serious bug. Evolution and Microsoft mentality.
On Thu, Jan 10, 2002 at 12:38:30PM -0500, Jeffrey Stedfast wrote: Actually the attached patch is the correct one. There is no need to memset and you should use PATH_MAX rather than 4096. No, the correct way is to malloc the space as needed. PATH_MAX doesn't exist on the Hurd. -- Adam Olsen, aka Rhamphoryncus
Re: serious bug. Evolution and Microsoft mentality.
On Thu, Jan 10, 2002 at 12:38:30PM -0500, Jeffrey Stedfast wrote: Actually the attached patch is the correct one. There is no need to memset and you should use PATH_MAX rather than 4096. Both is incorrect. PATH_MAX isn't required by POSIX and some systems don't have it (the Hurd for example). The Hurd simply doesn't have a limit (the GNU Coding Standards says arbitrary limits should be avoided, they are bad (think about the 640k limit, 1024 cylinder limit, etc)). If we have to define some limit it would be so large that it is not suitable for static allocation. You should use dynamic allocation and not limit you in any way. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpb7ykYD6UYl.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
While I agree with your statements, it's strictly not possible in this case - realpath() requires that the second argument be a string buffer of size PATH_MAX (read the manpage). SYNOPSIS #include stdlib.h char *realpath(const char *file_name, char *resolved_name); DESCRIPTION The realpath() function derives, from the pathname pointed to by file_name, an absolute pathname that names the same file, whose resolution does not involve ., .., or sym- bolic links. The generated pathname is stored, up to a max- imum of PATH_MAX bytes, in the buffer pointed to by resolved_name. Jeff On Thu, 2002-01-10 at 13:27, Jeroen Dekkers wrote: On Thu, Jan 10, 2002 at 12:38:30PM -0500, Jeffrey Stedfast wrote: Actually the attached patch is the correct one. There is no need to memset and you should use PATH_MAX rather than 4096. Both is incorrect. PATH_MAX isn't required by POSIX and some systems don't have it (the Hurd for example). The Hurd simply doesn't have a limit (the GNU Coding Standards says arbitrary limits should be avoided, they are bad (think about the 640k limit, 1024 cylinder limit, etc)). If we have to define some limit it would be so large that it is not suitable for static allocation. You should use dynamic allocation and not limit you in any way. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com
Re: serious bug. Evolution and Microsoft mentality.
Jeffrey Stedfast [EMAIL PROTECTED] writes: While I agree with your statements, it's strictly not possible in this case - realpath() requires that the second argument be a string buffer of size PATH_MAX (read the manpage). What about using canonicalize_file_name() instead whenever that function is available? moritz -- [EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/ GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
Re: serious bug. Evolution and Microsoft mentality.
Tomas Pospisek's Mail Lists wrote: On Thu, 10 Jan 2002, Erik Steffl wrote: Tomas Pospisek's Mail Lists wrote: On Wed, 9 Jan 2002, Mark Brown wrote: On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. I have yet to find out how to be able to see my inbox as well as all its subfolders (that's how it's set up on cyrus) from home. I am not sure if uw-imap supports anything else but mbox format by ^^^ Um a bit further down in my original posting I wrote: * ... yes, the problem is namespacing and that allthough there's a * standard it seems that either client (pine) or server cyrus 1.5.x from ^ that puzzled me a bit but since you put your comment right under uw-imap comment I thought you are refering to uw-imap at that point. * debian seem to be unable to get things straight between them. default and with mbox you cannot have folders that contain message and subfolders (it's one or another). so there's no such thing as inbox and its subfolders. if you're using maildir and it doesn't work properly then I don't know, haven't tried uw-imap with maildir... for cyrus INBOX seems to be the root directory. Incoming mail ends up in INBOX. Subdirs are created within INBOX. It might be that I didn't get cyrus the config right but AFAIK it's the default setup. But IMHO one should not be required to dig RFCs in depth to be able to use a mailclient. yes, for cyrus that's the way to go, all the email is in INBOX (which is user.username). you can put other stuff besides email in the root directory so the incoming personal email is all in INBOX, at least I think that's the rationale. I don't like it much either (since I only have email) but that's how it is. when/if you add e.g. NNTP or shared folders support you'll be OK with INBOX being there:-) erik
Re: serious bug. Evolution and Microsoft mentality.
On Mon, Jan 07, 2002 at 01:56:24PM -0500, Jeffrey Stedfast wrote: Yea, this is kinda painful currently but hopefully by 1.2 this will be much easier. We plan on making it so that you can add a new account using Standard Unix Mail Spool as the source type and pointing it at a directory and have our code automatically show all the mailboxes in the directory. Currently it will only accept single mbox files as sources. That will be very nice. Will you also let us point to Maildir's and have it Just Work? Maildir format allows us to continue using procmail and related programs without worrying about locking issues between Evolution and outside mail delivery programs and filters. It's not really a good idea to use symlinks because Evolution will lock the symlink file and if you have procmail running, it will lock the real mbox file and so if you try and access the same mbox file with both Evolution and procmail, things will end badly for you (ie corrupt mailbox). Correct. Thats why I plan to switch over completely to Maildir format. What happened? My symlink was erased! Gone! A new mbox file had been created from the contents of the original. Did you delete/expunge messages? I presume that you must have because otherwise the mbox would not have been rewritten. The only way to remove Unfortunately, no. I made no changes whatsoever to the mailboxes. I just entered them to see if the messages showed up, they did, then I exited. Thats when I noticed the symlinks had been blown away, and the resulting copied mailbox was bigger in size than the original! messages from an mbox file is to rewrite it to a new tmp file (minus the messages to be deleted) and then rename that tmp file back to its original name. Unfortunately, UNIX's rename() function clobbers symlinks and thus your problem. Well, alright. I did some research tonight. Before calling rename(), a call to realpath() would resolve the symlink to the correct real filename, and using that would give the correct result. An extra 3 lines of code (to find out how much storage is needed for the real path, to allocate it, then finally to call realpath()). Actually, Evolution plays very nice with other mail software on the system - you just have to not use symlinks. Supporting symlinks is easy. Not supporting them is un-Unixy. Evolution locks all mailboxes when it goes to access them to avoid mailbox corruption and so as long as the other system mail software does the same (which it should) then they will all live in harmony. Again, provided one uses Maildir mailboxes, things will be fine. But the thought occurs, Evolution should do its locking on the file returned from realpath() too. Hopefully the symlink-being-erased bug will be fixed soon. I think overall Evolution has made great strides and become a great program. I look forward to further evaluating it when this issue is fixed. This isn't a bug at all (as explained above). I vehemently maintain it is a bug, and until it is fixed I can't recommend Evolution. Cheers! Jonathan pgp9xbcr1NMtH.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
Jonathan Walther wrote: Subject: I tried evolution tonight. It is impressive work. I wanted to import my 62 mbox mailboxes and 6 maildirs. Well, for whatever reason, it didn't let me import my maildirs. And the interface for importing mailboxes is painful for 62 different mailboxes. So I looked at how to do it by hand, as any nice Unix application will easily allow one to do. It turns out to be fairly easy. Find a mail folder of the same type as the one you want to copy over, duplicate it with its new name, then symlink your original mbox to Foldername/mbox. It even has a nice function to convert my mboxes to maildirs, although new mailboxse are unfortunately not created in maildir format. I started evolution up, my folders were seen, I was happy. Then I exited. What happened? My symlink was erased! Gone! A new mbox file had been created from the contents of the original. This was bad enough, but it was a file of different size, indicating that QP (Quoted Printable) encoding had been redone, which is the cause of the GnuPG compatibility bug. So first evolution screwed me by making it so new mails going into the old mailbox won't be seen from evolution, but then it redoes the emails, causing GnuPG signatures to yield bogus bad matches! I hope that Evolution won't fall into the grave and anti-Unix error of assuming it is the only mail handling software on the system, nor that it can possibly know about all the mail software that is or might be in use on a system. Hopefully the symlink-being-erased bug will be fixed soon. I think overall Evolution has made great strides and become a great program. I look forward to further evaluating it when this issue is fixed. IMO the good solution for this kind of problems is to use IMAP. don't trust MUAs to work with files. (of course, Evolution should play nice with symlinks) erik
Re: serious bug. Evolution and Microsoft mentality.
On Tue, Jan 08, 2002 at 11:49:12PM -0800, Erik Steffl wrote: IMO the good solution for this kind of problems is to use IMAP. don't trust MUAs to work with files. (of course, Evolution should play nice with symlinks) Note that in his reply, the Evolution maintainer said the Unix rename() function erases symlinks, therefore your symlinks being erased is not a bug. What? It's not a bug? Oy vey. Let's see. Then there is the bug with GnuPG signatures not being verified correctly due to a Quoted Printable problem. The answer to that one was The problem is the fault of one of our libraries, and it isn't changing anytime soon, so this is not a bug. See a trend? That attitude scares me. Saying this would involve a major rewrite; we'll take care of it later would be acceptable. Saying the code does things this way; ergo it's not a bug just SCARES me. I feel like GNOME is just going to return us to the land of Microsoft, where software does unexpected things, and assumes all users are idiots, even if they are smart enough to use such fine Unix utilities as touch, chown, chmod, and ln. A user who doesn't know what he is doing will attempt to do everything from the provided GUI. Its shameful to assume that people that attempt to use vi to edit their configurations are also idiots. Jonathan pgpzpFxCMEfwz.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
le mer 09-01-2002 à 09:16, Jonathan Walther a écrit : Let's see. Then there is the bug with GnuPG signatures not being verified correctly due to a Quoted Printable problem. The answer to that one was The problem is the fault of one of our libraries, and it isn't changing anytime soon, so this is not a bug. *This* is the real problem with Evolution. It should use another GnuPG system. Evolution's behavior with mboxes is the right thing to do, as mboxes need to be locked. FYI, Evo handles perfectly Maildir trees, including those with symlinks, and can be used along with another MUA. the code does things this way; ergo it's not a bug just SCARES me. I feel like GNOME is just going to return us to the land of Microsoft, Calm down. Evolution is free software, that makes a huge difference with Microsoft software. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `' `- Debian GNU/Linux -- The power of freedom pgpO82zrsrU5F.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 10:29:43AM +0100, Josselin Mouette wrote: *This* is the real problem with Evolution. It should use another GnuPG system. Evolution's behavior with mboxes is the right thing to do, as mboxes need to be locked. Could you explain that? Using realpath() before locking the mbox would prevent any possible bad interactions between symlinking and locking. Its the Right Thing to do. What Evolution currently does is NOT. I object to attempts to lock me in to a single MUA. While I'm evaluating I expect to be able to continue using Mutt until I am confident enough in Evolution to cut the umbilical cord. FYI, Evo handles perfectly Maildir trees, including those with symlinks, and can be used along with another MUA. Yes, that is true. It will be nice if in the future Evolution will default to creating mailboxes in Maildir format, instead of mbox format. Or at least make it an option to create new Folders in Maildir format instead of assuming mbox. the code does things this way; ergo it's not a bug just SCARES me. I feel like GNOME is just going to return us to the land of Microsoft, Calm down. Evolution is free software, that makes a huge difference with Microsoft software. In the words of Eric Raymond: I dream of a world in which software does not suck. If free software isn't as much about software not sucking as it is about source being open, is there much point? I was trying to draw attention to the arrogant attitude that says this isn't a bug because I don't know how to fix it, or its hard to fix. Or worse, that ignores the tenets of the Unix Philosophy which made Unix so powerful in the first place. Even the bestest most uptodate modern GUI program can adhere to the Unix philosophy without compromising its ease of use in any way. And by adhering to its tenets, it lets itself be used with the rest of the Unix system in the most powerful way. Jonathan q.v. principle of of least surprise. pgpwAOgmiuDHA.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 01:47:02AM -0800, Jonathan Walther wrote: I object to attempts to lock me in to a single MUA. While I'm evaluating I expect to be able to continue using Mutt until I am confident enough in Evolution to cut the umbilical cord. Calm down. It could just be a bug and screaming about attempts to lock you into the software is probably not going to help convince people that what you're saying is sensible. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpNbzcMBdeJV.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
Zitiere Erik Steffl [EMAIL PROTECTED]: [1935 lines uselessly quoted] IMO the good solution for this kind of problems is to use IMAP. don't trust MUAs to work with files. IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. IMO nothing for newbies. *Tomas Pospisek
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. Most things (certainly mutt and kmail, I can't think of anything else I tried that gave me problems) interoperate quite happily with both UW IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't play with UW IMAP. MUAs that don't interoperate happily with both could probably be considered buggy - the main problem is likely to be namespacing and there's standard ways for the server to inform the client about the namespaces it uses. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgp6KJXB1Bew6.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd Mozilla at least works now with exchange :) Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: serious bug. Evolution and Microsoft mentality.
Il mer, 2002-01-09 alle 09:16, Jonathan Walther ha scritto: Let's see. Then there is the bug with GnuPG signatures not being verified correctly due to a Quoted Printable problem. The answer to that one was The problem is the fault of one of our libraries, and it isn't changing anytime soon, so this is not a bug. See a trend? That attitude scares me. Saying this would involve a it's called ximianite, from the company were it started. after it gets you, you'll suddenly start to answer to bug reports with phrases like it is not a bug, it is not our fault, it is XXX library, but we wrote 100.000 lines of GPL code. :) evolusion is a great program, really. but assumes way too much about the QI of the user. A user who doesn't know what he is doing will attempt to do everything from the provided GUI. Its shameful to assume that people that attempt to use vi to edit their configurations are also idiots. perfectly worded. -- Federico Di Gregorio Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] All programmers are optimists. -- Frederick P. Brooks, Jr. pgpV1Y0138CUC.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, 2002-01-09 at 01:43, Jonathan Walther wrote: On Mon, Jan 07, 2002 at 01:56:24PM -0500, Jeffrey Stedfast wrote: Yea, this is kinda painful currently but hopefully by 1.2 this will be much easier. We plan on making it so that you can add a new account using Standard Unix Mail Spool as the source type and pointing it at a directory and have our code automatically show all the mailboxes in the directory. Currently it will only accept single mbox files as sources. That will be very nice. Will you also let us point to Maildir's and have it Just Work? Maildir format allows us to continue using procmail and related programs without worrying about locking issues between Evolution and outside mail delivery programs and filters. Actually, Evolution already supports pointing to outside Maildir directories ;-) It's not really a good idea to use symlinks because Evolution will lock the symlink file and if you have procmail running, it will lock the real mbox file and so if you try and access the same mbox file with both Evolution and procmail, things will end badly for you (ie corrupt mailbox). Correct. Thats why I plan to switch over completely to Maildir format. What happened? My symlink was erased! Gone! A new mbox file had been created from the contents of the original. Did you delete/expunge messages? I presume that you must have because otherwise the mbox would not have been rewritten. The only way to remove Unfortunately, no. I made no changes whatsoever to the mailboxes. I just entered them to see if the messages showed up, they did, then I exited. Thats when I noticed the symlinks had been blown away, and the resulting copied mailbox was bigger in size than the original! Ah, I bet I know why... Evolution added an X-Evolution header to each message for status purposes. The X-Evolution header contains an encoded UID and message flags. That would also explain why it got bigger than the original file. messages from an mbox file is to rewrite it to a new tmp file (minus the messages to be deleted) and then rename that tmp file back to its original name. Unfortunately, UNIX's rename() function clobbers symlinks and thus your problem. Well, alright. I did some research tonight. Before calling rename(), a call to realpath() would resolve the symlink to the correct real filename, and using that would give the correct result. An extra 3 lines of code (to find out how much storage is needed for the real path, to allocate it, then finally to call realpath()). Actually, this isn't guaranteed to work :-( rename() is unfortunately limited to renaming files on the same file system, once you add symlinks to the equation - you could be leaping across file system boundaries and there isn't a way to tell (well, ok, so you can check st.st_dev and compare the 2). The only way I can think of to get around this is to create the tmp mbox file in the same directory as the original (after being realpath()'d). This may also have problems - what if you don't have write-permission in that directory? Actually, Evolution plays very nice with other mail software on the system - you just have to not use symlinks. Supporting symlinks is easy. Not supporting them is un-Unixy. Not as easy as you seem to think, you missed that rename doesn't work across file systems ;-) Anyways, I'll look into it... Evolution locks all mailboxes when it goes to access them to avoid mailbox corruption and so as long as the other system mail software does the same (which it should) then they will all live in harmony. Again, provided one uses Maildir mailboxes, things will be fine. But the thought occurs, Evolution should do its locking on the file returned from realpath() too. You are probably right. -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com
OT Re: serious bug. Evolution and Microsoft mentality.
On Wed, 9 Jan 2002, Jonathan Walther wrote: [...] A user who doesn't know what he is doing will attempt to do everything from the provided GUI. Its shameful to assume that people that attempt to use vi to edit their configurations are also idiots. (humor-mode t) Why? They would use emacs if they were not! (humor-mode nil)
Re: serious bug. Evolution and Microsoft mentality.
Evolution added an X-Evolution header to each message for status purposes. Merely _looking_ at a message with Evolution alters it? That is _truly_ evil. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 12:55:34PM -0600, John Hasler wrote: Evolution added an X-Evolution header to each message for status purposes. Merely _looking_ at a message with Evolution alters it? That is _truly_ evil. Maybe, but it's also commonplace. Consider how elm has for many years added Status: OR flags to read messages. -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpx53DaSLvKM.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 01:41:28PM -0500, Jeffrey Stedfast wrote: Unfortunately, no. I made no changes whatsoever to the mailboxes. I just entered them to see if the messages showed up, they did, then I exited. Thats when I noticed the symlinks had been blown away, and the resulting copied mailbox was bigger in size than the original! Ah, I bet I know why... Evolution added an X-Evolution header to each message for status purposes. The X-Evolution header contains an encoded UID and message flags. That would also explain why it got bigger than the original file. Fair enough. Pine does something similar. Can it be gauranteed that the Quoted Printable encoding hasn't been decoded then reencoded in the process? Actually, this isn't guaranteed to work :-( rename() is unfortunately limited to renaming files on the same file system, once you add symlinks to the equation - you could be leaping across file system boundaries and there isn't a way to tell (well, ok, so you can check st.st_dev and compare the 2). The only way I can think of to get around this is to create the tmp mbox file in the same directory as the original (after being realpath()'d). This may also have problems - what if you don't have write-permission in that directory? You solved the problem. That is the correct solution. After running realpath(), use dirname() and make the tmpfile in the same directory as the mailbox. The perception of a possible permissions problem is bogus. If you don't have permission in that directory to create the tmp mailbox, then you probably didn't have permission to blast over the original mailbox either. Suppose you successfully created the tmp file, but the rename() failed? I mean, it *could* happen. But its not likely. If such operations as creating the tmp file, or renaming it fail, that means the user has set the permissions himself, in which case he probably wanted that to happen. So don't complain, and leave the mailbox as is. Remember, stupid users will try to do everything from the GUI you provide. Users savvy enough to fiddle with ln, touch, chown, and chmod will get angry and exceedingly frustrated if you treat their actions the same as you treat those of your target stupid user. Again, provided one uses Maildir mailboxes, things will be fine. But the thought occurs, Evolution should do its locking on the file returned from realpath() too. You are probably right. I've thought about it some more, and I'm upgrading my maybe to a strong this is the proper way to do it. Symlinks should not be locked. They should be followed with realpath() and the real mailbox should be locked, like other MUA's do. This will truly make it compatible and play nicely on the Unix system. Cheers! Jonathan -- I am working to subvert from within ... umm ... by writing shoddy code ... and charging too much. -- Colin, Aug 21, 2001 pgpcOfMEOuAPT.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, 2002-01-09 at 16:20, Jonathan Walther wrote:
On Wed, Jan 09, 2002 at 01:41:28PM -0500, Jeffrey Stedfast wrote:
Unfortunately, no. I made no changes whatsoever to the mailboxes. I
just entered them to see if the messages showed up, they did, then I
exited. Thats when I noticed the symlinks had been blown away, and the
resulting copied mailbox was bigger in size than the original!
Ah, I bet I know why... Evolution added an X-Evolution header to each
message for status purposes. The X-Evolution header contains an encoded
UID and message flags. That would also explain why it got bigger than
the original file.
Fair enough. Pine does something similar. Can it be gauranteed that
the Quoted Printable encoding hasn't been decoded then reencoded in
the process?
not easily. Michael Zucchi and I will have to redesign libcamel to be
able to guarantee this and so must wait until we have time.
Actually, this isn't guaranteed to work :-(
rename() is unfortunately limited to renaming files on the same file
system, once you add symlinks to the equation - you could be leaping
across file system boundaries and there isn't a way to tell (well, ok,
so you can check st.st_dev and compare the 2).
The only way I can think of to get around this is to create the tmp mbox
file in the same directory as the original (after being realpath()'d).
This may also have problems - what if you don't have write-permission in
that directory?
You solved the problem. That is the correct solution. After running
realpath(), use dirname() and make the tmpfile in the same directory
as the mailbox.
[snip]
The attached patch will fix this issue.
Again, provided one uses Maildir mailboxes, things will be fine. But
the thought occurs, Evolution should do its locking on the file
returned from realpath() too.
You are probably right.
I've thought about it some more, and I'm upgrading my maybe to a
strong this is the proper way to do it. Symlinks should not be
locked. They should be followed with realpath() and the real mailbox
should be locked, like other MUA's do. This will truly make it
compatible and play nicely on the Unix system.
It also fixes this.
--
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
[EMAIL PROTECTED] - www.ximian.com
Index: ChangeLog
===
RCS file: /cvs/gnome/evolution/camel/ChangeLog,v
retrieving revision 1.1311.2.11
diff -u -r1.1311.2.11 ChangeLog
--- ChangeLog 2002/01/04 22:17:52 1.1311.2.11
+++ ChangeLog 2002/01/09 21:44:15
@@ -1,3 +1,11 @@
+2002-01-09 Jeffrey Stedfast [EMAIL PROTECTED]
+
+ * providers/local/camel-local-folder.c
+ (camel_local_folder_construct): If the mbox file is a symlink,
+ follow the symlink and get the One True Path so that we can
+ rewrite the mbox later without worrying about clobbering the
+ symlink.
+
2001-12-12 Jeffrey Stedfast [EMAIL PROTECTED]
* camel-folder-summary.c (content_info_load): Don't try setting a
Index: providers/local/camel-local-folder.c
===
RCS file: /cvs/gnome/evolution/camel/providers/local/camel-local-folder.c,v
retrieving revision 1.22
diff -u -r1.22 camel-local-folder.c
--- providers/local/camel-local-folder.c2001/10/28 05:10:55 1.22
+++ providers/local/camel-local-folder.c2002/01/09 21:44:15
@@ -24,6 +24,7 @@
#endif
#include stdlib.h
+#include limits.h
#include sys/types.h
#include dirent.h
#include sys/stat.h
@@ -191,7 +192,14 @@
lf-folder_path = g_strdup_printf(%s/%s, root_dir_path, full_name);
lf-summary_path = g_strdup_printf(%s/%s.ev-summary, root_dir_path,
full_name);
lf-index_path = g_strdup_printf(%s/%s.ibex, root_dir_path,
full_name);
-
+
+ /* follow any symlinks to the mailbox */
+ if (lstat (lf-folder_path, st) != -1 S_ISLNK (st.st_mode)
+ realpath (lf-folder_path, folder_path) != NULL) {
+ g_free (lf-folder_path);
+ lf-folder_path = g_strdup (folder_path);
+ }
+
lf-changes = camel_folder_change_info_new();
/* if we have no index file, force it */
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 01:20:16PM -0800, Jonathan Walther wrote: The perception of a possible permissions problem is bogus. If you don't have permission in that directory to create the tmp mailbox, then you probably didn't have permission to blast over the original mailbox either. It is very likely. Allowing to create files in the spooldir of a mbox style spool means you are able to actually fake or dos other's mail receiving. It is prefered to have only write access to you own mailbox. Normally a trusted application is granted more access by running it sgid mail. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: serious bug. Evolution and Microsoft mentality.
[EMAIL PROTECTED] wrote: Zitiere Erik Steffl [EMAIL PROTECTED]: [1935 lines uselessly quoted] IMO the good solution for this kind of problems is to use IMAP. don't trust MUAs to work with files. IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating combination of MUA and IMAPd is pine together with uw-imapd which is about as configurable as your sunglasses. With other Linux combinations you'll have to uw-imap is a good choice for beginner (you only need to apt-get install it), while it's true that it cannot be configured much (and the configuration is compile-time) it already provides much better functionality then file based mail storage (no file access conflicts, access to email over network (supports ssl), access to other stuff) as far as MUAs go I think the new ones have fairly good support for IMAP (mutt (could be better), netscape, evolution etc.) [I use netscape and mutt mostly] go fiddling with Prefix|View = INBOX. | INBOX* | INBOX.% | INBOX etc. IMO nothing for newbies. I only have experience with cyrus (with sieve) and it's quite a hell, it provides almost no feedback, docs are all over the place etc. works well but very unpleasant to handle. also,the version in debian is extremely old. erik
Re: serious bug. Evolution and Microsoft mentality.
Branden Robinson [EMAIL PROTECTED] writes: On Wed, Jan 09, 2002 at 12:55:34PM -0600, John Hasler wrote: Evolution added an X-Evolution header to each message for status purposes. Merely _looking_ at a message with Evolution alters it? That is _truly_ evil. Maybe, but it's also commonplace. Consider how elm has for many years added Status: OR flags to read messages. Even Gnus (in Emacs) does this. Adding status-headers I at least doesn't find any problems with. Changing coding to QP is a bad thing though. /Jackson
Re: serious bug. Evolution and Microsoft mentality.
Thank you for the patch. To make it work, you need to define the variable folder_path. I would recommend this: char folder_path[4096]; And then before using it, do this: memset(folder_path, 0, sizeof folder_path); Cheers. Jonathan On Wed, Jan 09, 2002 at 04:57:34PM -0500, Jeffrey Stedfast wrote: You solved the problem. That is the correct solution. After running realpath(), use dirname() and make the tmpfile in the same directory as the mailbox. [snip] The attached patch will fix this issue. Again, provided one uses Maildir mailboxes, things will be fine. But the thought occurs, Evolution should do its locking on the file returned from realpath() too. You are probably right. I've thought about it some more, and I'm upgrading my maybe to a strong this is the proper way to do it. Symlinks should not be locked. They should be followed with realpath() and the real mailbox should be locked, like other MUA's do. This will truly make it compatible and play nicely on the Unix system. It also fixes this. pgpUE6uxH7my2.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
Oops, copy/paste-o when migrating the patch to the 1-0 code base. Jeff On Wed, 2002-01-09 at 19:28, Jonathan Walther wrote: Thank you for the patch. To make it work, you need to define the variable folder_path. I would recommend this: char folder_path[4096]; And then before using it, do this: memset(folder_path, 0, sizeof folder_path); Cheers. Jonathan On Wed, Jan 09, 2002 at 04:57:34PM -0500, Jeffrey Stedfast wrote: You solved the problem. That is the correct solution. After running realpath(), use dirname() and make the tmpfile in the same directory as the mailbox. [snip] The attached patch will fix this issue. Again, provided one uses Maildir mailboxes, things will be fine. But the thought occurs, Evolution should do its locking on the file returned from realpath() too. You are probably right. I've thought about it some more, and I'm upgrading my maybe to a strong this is the proper way to do it. Symlinks should not be locked. They should be followed with realpath() and the real mailbox should be locked, like other MUA's do. This will truly make it compatible and play nicely on the Unix system. It also fixes this. -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 01:47:02AM -0800, Jonathan Walther wrote: I object to attempts to lock me in to a single MUA. so do i. it's evil. While I'm evaluating I expect to be able to continue using Mutt until I am confident enough in Evolution to cut the umbilical cord. i learnt long ago not to evaluate new MUAs on my main mailbox - or even with my usual login account. strange new MUAs (especially GUI ones) have a nasty habit of doing weird shit to mailboxes. they move it around or helpfully convert it to their own non-standard format or some other annoying thing. to evaluate an MUA safely, create another account on your system (you can have mail delivered to it by setting up .forward to CC your real account's mail to it) and login as (or su - to) that userid before running the MUA. better yet, just stick with mutt. It Workstm :-) craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 12:55:34PM -0600, John Hasler wrote: Evolution added an X-Evolution header to each message for status purposes. Merely _looking_ at a message with Evolution alters it? That is _truly_ evil. Even mailx does *that*. -- Marc Wilson [EMAIL PROTECTED] [EMAIL PROTECTED] pgplnb1TN5XeH.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 07:38:43PM -0500, Jeffrey Stedfast wrote:
Oops, copy/paste-o when migrating the patch to the 1-0 code base.
Here is the correct patch for the 1.0.x branch. Hopefully the Debian
maintainer will apply it? I am creating an Evolution 1.0-5.1 package
on my system with the patch applied. I haven't seen so many signal 11's
in aeons.
Index: camel/providers/local/camel-local-folder.c
===
RCS file: /cvs/gnome/evolution/camel/providers/local/camel-local-folder.c,v
retrieving revision 1.22
diff -u -r1.22 camel-local-folder.c
--- evolution/camel/providers/local/camel-local-folder.c2001/10/28
05:10:55 1.22
+++ evolution/camel/providers/local/camel-local-folder.c2002/01/09
21:44:15
@@ -23,8 +23,9 @@
#include config.h
#endif
#include stdlib.h
+#include limits.h
#include sys/types.h
#include dirent.h
#include sys/stat.h
#include unistd.h
@@ -173,8 +174,9 @@
CamelFolder *folder;
const char *root_dir_path, *name;
struct stat st;
int forceindex;
+ char folder_path[4096];
folder = (CamelFolder *)lf;
name = strrchr(full_name, '/');
@@ -190,8 +192,16 @@
lf-base_path = g_strdup(root_dir_path);
lf-folder_path = g_strdup_printf(%s/%s, root_dir_path, full_name);
lf-summary_path = g_strdup_printf(%s/%s.ev-summary, root_dir_path,
full_name);
lf-index_path = g_strdup_printf(%s/%s.ibex, root_dir_path,
full_name);
+
+ /* follow any symlinks to the mailbox */
+ memset(folder_path, 0, sizeof folder_path);
+ if (lstat (lf-folder_path, st) != -1 S_ISLNK (st.st_mode)
+ realpath (lf-folder_path, folder_path) != NULL) {
+ g_free (lf-folder_path);
+ lf-folder_path = g_strdup (folder_path);
+ }
lf-changes = camel_folder_change_info_new();
/* if we have no index file, force it */
pgpyLL48mwAHu.pgp
Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Wed, Jan 09, 2002 at 06:19:55PM -0800, Marc Wilson wrote: On Wed, Jan 09, 2002 at 12:55:34PM -0600, John Hasler wrote: Evolution added an X-Evolution header to each message for status purposes. Merely _looking_ at a message with Evolution alters it? That is _truly_ evil. Even mailx does *that*. IMHO, it is not evil to append to the headers of the message. Every MTA does that. But if you delete stuff of alter the actual message, then it is evil.. - Adam
