GNOME Bugzilla – Bug 625351
Sending through sendmail reports error
Last modified: 2013-09-14 16:54:29 UTC
I'm running the git master of evo and related programs (last built today) in a gtk+-3.0 environment. Evolution runs; however, when I send mail (via sendmail) the following happens: 1. The mail is moved to the outbox. 2. The mail is sent. This is correct, but what doesn't happen is that the outbox is purged and the mail is copied to my sent folder. The e-mail stays in the outbox and, worse, is periodically resent. I have to manually get rid of the e-mail in the outbox folder.
One more thing: The following messages appear on the console when I send: evolution-mail-Message: Error occurred while existing dialogue active: Could not send message: Invalid argument
Thanks for a bug report. Through sendmail, then is it an IMAP account or POP account? (just to have more accurate description).
It's a pop account (for receiving mail). About half the time I'm using evolution on the pop account's server. Sending mail is via sendmail, no matter what box I'm running evolution on. One more thing, I basically clone .evolution and .gconf/apps/evolution on several machines and keep them synced using rsync (run when gnome isn't running). That way my laptops etc., have identical local copies of everything.
Here's another folder-related problem (probably different). I use procmail to filter incoming spam and/or viruses and suspicious mail is put into two files in ~/Mail/Inbox.{spam,virus} on my office computer. When I'm out of the office, I use nfs to link the two remotes to the same mount points on my remote machine. Evolution is set up to have 2 mbox accounts (with local delivery) linked to these files. Since switching to gtk+-3.0 I've noticed that these folders never have anything in them when I'm on the remote machine. Worse, once evolution updates its folders, these files are empty (which is what should happen), but nothing appears in evo's folders. I've checked that the NFS links are there and readable (before running evolution, they also have stuff in them). So two issues: 1. why isn't the mail making it to the right folder in evo, and more importantly, why is evolution purging the folder if there's an error. (Needless to say, I haven't a clue if this is related to the outbox bug).
With regards to comment 4, it turns out the problem is NOT NFS related. I'm on my main machine now, i.e., the one where the real mbox files reside, and evolution isn't reading them properly. The files are emptied, but nothing appears in the folders.
Also on the outbox folder issue. I just sent an email that was delivered to sendmail. The outbox folder count became (1); however, when I switched to the folder, nothing showed up in the message list. I expunged the folder (ctrl-E) and the just sent message appears. I deleted it, expunged the folder, and the count went to 0.
I updated and reinstalled evo eds, etc., to incorporate Matthew Barnes' migration of .evolution to .configure and .local. That seemed to work, but had no effect on the two issues discussed here. In addition, message filtering for pop accounts seems to have broken, but I'll log that separately.
Hmm, I do not have issues with local Outbox as you describe, but I use SMTP. I'll try with sendmail tomorrow.
Created attachment 166811 [details] [review] eds patch for evolution-data-server; Yeah, the sendmail sending was broken. Matt added more error checking, which led to the "Invalid argument" error message, and because there was the error, Evolution expected message not being sent. The error comes from fsync call of CamelStreamFs, which was created with a file descriptor of stdout, which I think is the cause why fsync fails. I'm changing the code to ignore CamelStream::flush errors in CamelStreamFilter::close method, like it was doing that before.
Created commit 5a25fc9 in eds master (2.31.6+)
If you're going to ignore the error, just pass NULL. Passing a GError is always optional.
Yup, I just wasn't sure with your check routine, whether it'll claim false-positive or not, and I was lazy to test/search it, thus made it this way.
Nah, those runtime checks can only compare the GError to the return value of the GError is non-NULL. If the GError is NULL the runtime checks are skipped entirely.
grr... I meant "IF the GError is non-NULL" in the first sentence.
I recompiled and the problem is fixed. Thanks Milan. Not to be greedy, but the issue I raised in comment #4 is still present and leads to mail being lost. Should I file a separate bug report?
I've reopened this, because the 2nd issue is not fixed (see comment #4 and on). I'll file a separate bug report if you'd prefer. Note this leads to mail (thankfully junk here) being lost!
Here's another clue perhaps. I selected a bunch of messages and tried to move them to the Inbox.Spam folder. Evolution blinks, every selected message is duplicated, and every second message in the folder is selected, but nothing is moved to the destination folder. There is no output in the notification area or on the console. Restarting evolution gives the same source folder, but now the destination folder has been populated (once). Here're a couple of other random observations: 1. Running ls -l `find -name "Inbox.Spam*" -print` in ~/.local/share/evolution gives ./mail/mbox/home/ronis/Mail/Inbox.Spam: total 8 -rw-r--r-- 1 ronis ronis 6144 2010-08-09 23:02 folders.db ./mail/spool/home/ronis/Mail/Inbox.Spam: 2. My preferences list the spam mbox as having "Local Spam" as the account name. The Folder is simply listed as "Spam" in the folder list. 3. The preferences for receiving mail list the Path: as simply Inbox.Spam. This isn't new, but the path is quite correct, rather ~/Mail/Inbox.Spam.
I would suggest to disable gtk3 for now, because it is not compilable with recent tarball releases and the gtk3 will not make it in 2.32 anyway, so it's better to wait until it's good enough (I would expect a bit more than another month, till the gtk3 API settles). I also noticed osme issues with scroll update, because I scroll but the content of the ETree isn't, though my movements and clicks are counted properly. it might be something with our gtk-compat.h too, I do not know yet, but as gtk3 was postponed, then we may look on other stuff. Let's disable gtk3 for evo modules (and all other, if you can), and wait until it's good enough to be used. Thanks. (I'm closing this as fixed again, but let's reevaluate when gtk3 and evo is ready).
Hi Milan (welcome back). This is not a gtk3 issue. I've purged the entire gnome tree and rebuilt everything (without gtk3) for gnome 2.31.90. Evolution was built from the release tarballs as well as from git/master (along with all supporting libs etc). The problem remains (i.e., comment 4). This is critical since mail is being lost. Please reopen, or if you'd prefer, let me know and I'll file a separate bug.
(In reply to comment #19) > Please reopen, or if you'd prefer, let me know and I'll file a separate bug. Please file a new bug, and write its number here, as a reference. Thanks. If you've more detailed observations, maybe updated steps, interesting evo console output from the start, then add it there too. Thanks.
OK, I've filed a new bug 627952