Re: How to implement save_empty on maildir?
Hallo Derek,
Derek Martin inva...@pizzashack.org wrote:
On Sun, Jun 28, 2009 at 07:42:53PM +, Jörg Sommer wrote:
Rocco Rutte pd...@gmx.net wrote:
* Wu, Yue wrote:
I want to let mutt deletes empty maildirs automatically, but 'save_empty'
only
works for mbox, why? How to achieve it for maildir?
It doesn't work for maildir. I'm not sure why, but probably because
removing an empty maildir has the potential to break something as it
cannot be done atomically.
Mutt can rename the maildir to $maildir-mutt-remove and then remove the
subdirectories and then the $maildir-mutt-remove. The rename can be done
atomically.
At first glance, this seems like a good solution, but actually it is
not:
1. There may be an existing directory by that name already.
Even if Mutt checks for the existence of it first, it is not safe,
because the user could (without knowing the behavior of Mutt)
create such a directory in between the time that Mutt checks, and
executes the rename().
So, create the directory yourself to ensure it's there and yours.
% cat rename-test.c
#include stdio.h
#include sys/stat.h
int main(void)
{
mkdir(mdir-mutt-delete, 0) /* this is a temporary directory to
ensure rename doesn't replace an
existing directory */
|| rename(mdir, mdir-mutt-delete);
return 0;
}
The good case:
% mkdir mdir
% strace ./rename-test
…
mkdir(mdir-mutt-delete, 0)= 0
rename(mdir, mdir-mutt-delete) = 0
…
% ls -ld mdir*
drwxr-xr-x 2 joerg users 40 2. Jul 09:51 mdir-mutt-delete
The bad case:
% mkdir mdir mdir-mutt-delete
% strace ./rename-test
…
mkdir(mdir-mutt-delete, 0)= -1 EEXIST (File exists)
% uname -a
Linux ibook 2.6.29 #1 Fri Mar 27 07:38:10 CET 2009 ppc GNU/Linux
2. $maildir may be a symlink. I'm not sure how mutt handles the
general case of a maildir being a symlink, but assuming that's
allowed, then in this case, it would fail briliantly.
If the maildir is a symlink, the question is what behaviour is expected?
If it's enough to remove the symlink, that's pretty easy. If mutt should
remove the target of the symlink, mutt can do it as described above.
Mutt would rename() the symlink, and then delete it. The user may
be using something like fetchmail to deliver mail to the maildir
(the actual directory which was the target of the symlink) in which
case Mutt will NEVER AGAIN see new mail in that directory, at least
until such time as the user realizes what happened and takes some
action to fix the problem.
Because the tool rm removes the symlink, I think the user should expect
that the symlink gets removed and not the target.
3. In some cases, it may be possible that the directories $maildir and
${maildir}-mutt-remove would not be on the same file system
As mutt creates the temporary directory, mutt can say where the
directory should be created. If mutt creates the temporary directory
in the same directory as the maildir is, I see no problems.
Otherwise, I thinks it's no problem to fall back to the current behaviour
and do _nothing_ or print an error message. Don't care for special cases.
The main case can be handled as described above.
Bye, Jörg.
--
Viele Leute glauben, dass sie denken, wenn sie lediglich
ihre Vorurteile neu ordnen.
Mutt 1.20. --GPG--
Hello, Testing Mutt 1.20. GPG asks my passphrase but doesn't accept it. I don't really know where to start looking for figuring this out. from config.log: --- $ ./configure -C --prefix=/opt/mutt --enable-pop --enable-imap\ --enable-smtp --enable-debug --with-gss --with-gnutls --with-sasl --with-idn --enable-hcache --- output of version: - $ /opt/mutt/bin/mutt -version Mutt 1.5.20hg (2009-06-26) [...] System: Linux 2.6.27-14-generic (i686) ncurses: ncurses 5.6.20071124 (compiled with 5.6) libidn: 1.8 (compiled with 1.8) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Jun 15 2006 21:19:27) Einstellungen bei der Compilierung: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/opt/mutt/share/mutt SYSCONFDIR=/opt/mutt/etc EXECSHELL=/bin/sh -MIXMASTER --snip--- PS: after make install i manually changed permissions and group of /opt/mutt/bin/mutt_dotlock, because install failed at it: -- $ ls -l mutt_dotlock -rwxr-sr-x 1 jan mail 24118 2009-06-27 16:13 mutt_dotlock -- hints greatly appreciated jan
Re: Mutt 1.20. --GPG--
Hi, * Jan-Herbert Damm wrote: GPG asks my passphrase but doesn't accept it. What gpg setup did you use? contrib/gpg.rc? It's not gpg that's asking but mutt. So maybe mutt doesn't call gpg at all or in a wrong way... Rocco pgp7cJuKZz5L7.pgp Description: PGP signature
Re: Mixmaster
Hi, * sigi wrote: I'm using mixmaster 3.0.0-2 with mutt 1.5.18-6+b1 on debian lenny and it all works just fine. So the manual seems to be very outdated Updated now, thanks. Rocco pgpJfQ9J5Fo79.pgp Description: PGP signature
Re: Mutt 1.20. --GPG--
Rocco Rutte wrote on 02.07.09: Hi, * Jan-Herbert Damm wrote: GPG asks my passphrase but doesn't accept it. What gpg setup did you use? contrib/gpg.rc? It's not gpg that's asking but mutt. So maybe mutt doesn't call gpg at all or in a wrong way... I guess I'm running into the same trap as just a few days ago: the ubuntu set up with the /etc/Muttrc.d/* files being sourced from /etc/Muttrc. Whereas my /opt/mutt/etc/Muttrc does something else. - $ locate gpg.rc /etc/Muttrc.d/gpg.rc /home/jan/SRC/mutt-1.5.20hg/contrib/gpg.rc /opt/mutt/share/doc/mutt/samples/gpg.rc /usr/share/doc/mutt/examples/gpg.rc - Let me fumble with this for a while. I am sure the answer resides in there somewhere. jan, and thanks!
Re: Attach to shared mailbox in Exchange
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thursday, July 2 at 09:34 AM, quoth Chris: Does anyone know how can I attach to a shared mailbox in Exchange from Mutt? I'm running mutt 1.5.20. It may not be possible - that sounds like a MAPI-only function (translation: Outlook-only). ~Kyle - -- In theory, theory and practice are the same. In practice, they are not. -- Lawrence Peter Yogi Berra -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKTNE9AAoJECuveozR/AWeHd8P/iEugwT9BWeFUPKAE57mdmuX 2Jwka5UC7JY+u6idLMcnIGMY2L3kBEu9dHNU54fXMBylHONbfQUT9QRLdU+vPHqx yszBAE1RowEoiskk1jL0uqcY1N4halGJ1JfymmYrC1j98XnSea7ZNc4ey7j6R6J5 cqFCMzHhvK7u/xQ9bsu9PBFtPhYmXj7WvfEVG02vh2RaQCwon+RYExdYi9WpRlaQ XrxSZLWhXOGmO22p2FwfGH4WuD8PFw7cZSp7iewksBakYl241QdVdVhgAvvs+TZE aZ1w9WQzHgxpiVIul2Pm1cs8h6HntzWVcHraWPlOyDFIechxLUGBVsB8ge9feWPZ /3Rnyv7Up0JCubdvD7KAojlKYnYcPg/5Om1NzVnuDlh7ezbJB4f9R9an81UcG3qL 9Cep9o03rzVPiX7JMLB8V0VBEkZJ1ZWISAdN7LQuFfues42UyAaclIsp9V1JXDC5 q4qOuA57UQNTLN5uO5L18x9xDv392E1/XP0c86OtN3lrdvRVRTXluG1jtAyu5XHb cLY+37a+23yQif4Z3jT5dpqP6zDdlDdh6mPVtXPKQX1kZwhw39J69jvdxO0qSnH1 Iq2EbH/W6mHqVne3U0XhiHMpjIqjHYiyYMIXCqwFREkPFuVUlaTNOIGtMm0RAgHZ fsNp3FMxIcdMlLPV1thu =p5hS -END PGP SIGNATURE-
Re: sporadic acs characters problem with Mutt in Terminal.app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, July 1 at 04:42 PM, quoth William Yardley: On Fri, Jun 26, 2009 at 08:47:44AM -0500, Kyle Wheeler wrote: Weird... That sounds like something might be wrong either with your terminal library or your termcap. What terminal do you use, and what's the value of $TERM? (I'm assuming that since you use OpenBSD you know what I'm talking about. :) Both was answered in my original post, and the version of ncurses is the one that's mentioned in mutt -v (should be 5.2.20010224). Ooops, sorry, I should have re-read the top. For what it's worth, I've found nsterm-16color (with one or two modifications) to be the best TERM entry for my Apple Terminal. But since not all versions of ncurses have it (and since I modified it a little), I keep a copy handy in ~/.termcap/. Agreed that maybe something is wrong, but the point is that generally, they work fine. It's just that occasionally, something gets goofed up. Well, that's the thing with terminal stuff - you can be mostly right and never know anything's amiss until you use whatever rare feature happens to be set up wrong. But after re-reading your original email, I don't think it's a TERM thing. Since it doesn't affect the $editor, it sounds like it is something getting messed up in mutt's internals (or the terminal library), rather than something getting messed up in the terminal itself. That version of ncurses is awfully old; assuming that minor version number is a date, your ncurses is almost a decade old by now. It's entirely possible there's a bug in it that they've long-since fixed. Is it possible to install a more recent version of ncurses? ~Kyle - -- I see the pain on your face when you say the word intellectual, because it has so many syllables in it. -- Clive James -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKTNQfAAoJECuveozR/AWeZBcP/igoJWKaAxb9wKpgPzHDdbRG b2B+7p/aGHZM3MRz3WJOSgiQg6yjYW18JZoNi4HQoCAN6jqEkjc3Fu/FJQN6csxH W5Ku4zN7fhyhAsRpd+CeM30/c8F6lcl2XgF4P2q3JfWgjCWAq0ObEDHLLj6Jpjrr ofT5EhcopmFJtG1CUFaSRbrLiBgioIesOuEWc30Ls3j99h0aKeHYs+ex+xFliF5E +2Y/rwAFQkzVtBEBGqD8BCevEwrJdh5ImIdpwLEJ0OdQIJLMAWJBO6doKARUaYQ8 3hkW9Eoo9i9tO8UOD53OcGGhSUUT6489p0+JwfB9eOoyBOmJnI6RqslhYjKtqRKL SjHupVg5vy07QSZhA+gEd3g0lpHU80WAmMVcBYn+JSJsoi1NbX2XO5H/ByqHYhRu vaWBCjrA2stZleQH4PpUfC9yOr+2eho87nGZd+dK888PN2V7r5nePpk4MJBcyMRl lUj3ANpc2E9khc5L77TKi/rGQxFGnK7Xb9A8gnzejQzXkbwWDsphYS1d1CA4a3Pp xJGkrkfaKt/FjooU3i7kdGrpdjL+Xkgt7qCGi9ctKJG+fHABLocO8Vn0zHmF3w0m Ur6xikh+MLoCNwHheKrGUGPIrPNciiaobHxrGsgcuA2bhYWyMVT/i+jhaBXq5cbB 8p3GlL0RNsWzFRdPOocb =h0BJ -END PGP SIGNATURE-
Re: How to implement save_empty on maildir?
Hi Jörg,
On Thu, Jul 02, 2009 at 08:10:21AM +, Jörg Sommer wrote:
So, create the directory yourself to ensure it's there and yours.
% cat rename-test.c
#include stdio.h
#include sys/stat.h
int main(void)
{
mkdir(mdir-mutt-delete, 0) /* this is a temporary directory to
ensure rename doesn't replace an
existing directory */
|| rename(mdir, mdir-mutt-delete);
return 0;
}
There are several problems with this. If the directory exists when
you do the mkdir, it fails with no clear course of action to take to
fix the failure; that seems like clearly a bug to me. Also, if some
process puts a file in mdir-mutt-delete before you rename it, the
rename will fail. In either case, Mutt didn't do what you told it to
do (remove the maildir when it's empty). You can't code stuff that
works sometimes in applications that other people are going to use...
Also, while this test may work as you expect on your system, not all
operating systems on which Mutt runs may have the same semantics.
More importantly these operations are not atomic, and therefore can not
be done safely. It is possible, for example, for the user to do
exacty the same thing, in between the time you create the directory,
and the time you rename the maildir.
It also means the user can not use ${maildir}-mutt-delete as a mailbox
name (or anything else). Which in turn means that the user must KNOW
that they can't use it safely. That's yucky (to say the least)... the
user should not need to know the intimate details of the
implementation of your software in order to use it safely, by and
large.
2. $maildir may be a symlink. I'm not sure how mutt handles the
general case of a maildir being a symlink, but assuming that's
allowed, then in this case, it would fail briliantly.
If the maildir is a symlink, the question is what behaviour is expected?
Presumably the expected behavior is that it should work exactly the
same way whether it's a symlink or not. For the most part, this is
the point of symlinks; to make transparent the ability to have files
appear to exist someplace other than where they actually exist.
If it's enough to remove the symlink, that's pretty easy. If mutt should
remove the target of the symlink, mutt can do it as described above.
As I described previously, this is clearly unacceptable. New mail
will accumulate, but Mutt won't see it, because it's configured to
look at a non-existant symlink.
Mutt would rename() the symlink, and then delete it. The user may
be using something like fetchmail to deliver mail to the maildir
(the actual directory which was the target of the symlink) in which
case Mutt will NEVER AGAIN see new mail in that directory, at least
until such time as the user realizes what happened and takes some
action to fix the problem.
Because the tool rm removes the symlink, I think the user should expect
that the symlink gets removed and not the target.
Why should the user expect that it gets removed? Even if you document
it, the user may set it up as a symlink, and then set this option on
the folder at a later time, and never make the connection between what
they just did and the problem they just caused. This is exactly why
most sysadmins have a job. ;-)
3. In some cases, it may be possible that the directories $maildir and
${maildir}-mutt-remove would not be on the same file system
As mutt creates the temporary directory, mutt can say where the
directory should be created. If mutt creates the temporary directory
in the same directory as the maildir is, I see no problems.
I already gave you two examples where it IS a problem. I'll spell it
out:
/home/user/mail: root of user's mail directory
/home/user/mail/maildir1: a specific folder which is NFS-mounted
from another system (because the user is slightly crazy).
/home/user/mail/maildir1-mutt-delete: a directory under
/home/user/mail, on the same device
In other words, the user executed something like:
/sbin/mount -t NFS server:/my/other/maildir /home/user/mail/maildir1
Now you have maildir1 and maildir1-mutt-delete on two different
physical filesystems. That won't work (a call to rename will fail;
you need to copy the files to the new location, and unlink() the old
ones).
Another case: The user ran out of space in /home, so created a
directory in /var for more folders. But they still want the maildir
structure to look like it's all in one place, so they do this:
/sbin/mount -o bindmount /var/my/new/maildr /home/user/mail/maildir1
Same problem as before. This may seem weird to you (and it probably
should), but I promise you, people really do this stuff. Because they
can, and because they think it's cool. And for the most part, it
works just fine... until an application like Mutt comes along and
makes assumptions about the arrangement of the filesystem.
Some
Re: Attach to shared mailbox in Exchange
On Thu, Jul 02, 2009 at 10:24:45AM -0500, Kyle Wheeler wrote: On Thursday, July 2 at 09:34 AM, quoth Chris: Does anyone know how can I attach to a shared mailbox in Exchange from Mutt? I'm running mutt 1.5.20. It may not be possible - that sounds like a MAPI-only function (translation: Outlook-only). Evolution now does this (though it may be buggy): http://openchange.org/ -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpGA13fLQgQb.pgp Description: PGP signature
