bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with "mail"


From: Alain Magloire
Subject: Re: problems with "mail"
Date: Thu, 28 Mar 2002 10:04:54 -0500 (EST)

> 
> Bonjour,
> 
> Command line parsing couldn't be the cause of the problem:
> 
> > in the case of frm.c(main.c):
> [...]
> > argc -= c;
> > 
> > will set argc to 0  and mailbox_name will always be NULL, ignoring
> > any --maildir=URL directives. 
> 
> No, it won't. After mu_argp_parse, 'c' is set to the index of the
> _next not processed option_. Thus, given the input of
> `frm --maildir /var/mail mbox', c equals 3 after mu_argp_parse, which
> yields *(argv+3)="mbox". As about --maildir option, it is taken care
> of by mu_argp_parse itself.

# cd ~/GNU/mailutils/frm
gdb .libs/frm
...
(gdb) b main
Breakpoint 1 at 0x804997c: file frm.c, line 302.
(gdb) r --mail-spool=pop3://localhost
Starting program: /home/alain/GNU/mailutils/frm/.libs/frm 
--mail-spool=pop3://localhost

Breakpoint 1, main (argc=2, argv=0xbffff8e4) at frm.c:302
302       char *mailbox_name = NULL;
(gdb) n  
303       size_t total = 0;
(gdb) display mailbox_name
1: mailbox_name = 0x0
(gdb) display c
2: c = 134531144
(gdb) n
307       mu_argp_parse (&argp, &argc, &argv, 0, frm_argp_capa, &c, NULL);
2: c = 134531144
1: mailbox_name = 0x0
(gdb) 
310       argc -= c;
2: c = 2
1: mailbox_name = 0x0
(gdb) n
311       argv += c;
2: c = 2
1: mailbox_name = 0x0
(gdb) display argc
3: argc = 0
(gdb) n
313       if (argc)
3: argc = 0
2: c = 2
1: mailbox_name = 0x0
(gdb) display argv[0]
4: argv[0] = 0x0
(gdb) 

The call to
status = mailbox_create_default (&mbox, mailbox_name);
will always ignore the option --mail-spool. 

> > For mail/mail.c(main):  it is more subtile, 
> [...]
> > args.file always return NULL and mailbox_create_default(&mbox, NULL) will
> > always be call in ignoring any --maildir directives.
> 
> Again, this is not so. Parsing of --maildir is done by mu_argp_parse
> itself and is not connected in any way with args.file. Now,
> args.file is actually initialized to NULL in mail.c:290, as you
> have pointed out. But between this point and checking it in mail.c:345
> there is a call to mu_argp_parse, which in turn calls parse_opt,
> which in its turn sets argp.file (see mail.c:70-80).

mailbox_create_default() is always call with the second argument NULL.
What happen when you do:

# mail --mail-spool=pop://localhost

not ok.

# FOLDER=pop://localhost mail

Ok.

# mail --mail-spool=imap://localhost

not ok

# FOLDER=imap://localhost mail

oops!! dumps core. Bactrace shows trying to access a null.
(Using our IMAP server)

> Now, let's take a look at the problem  in more detail:
> 
> 1.
> >> In short, I haven't been able.
> >> While mailx would show my mail in /var/mail/jordi just invoking it with
> >> "mail", mailutils seems to only look after ~/mbox by default.
> 
> One of the possible reasons is inconsistent setting of FOLDER or MAIL
> variables: the code in mailbox_create_default() favors these over
> all other settings (I am not sure this behavior correct, though).

Only if you the argument is NULL.  Doing
mailbox_create_default(.., NULL); // will favor environment FOLDER and MAIL

mailbox_create_default(..,"/home/joe/mbox"); // wil use /home/joe/mbox

> 2.
> >> 65587:address@hidden:...mailutils-20020326/debian$ mail -f/var/mail/jordi 
> >> =20
> >> mail (mailutils) 0.0.9c, Copyright (C) 2001 Free Software Foundation, Inc.
> >> mail is free software with ABSOLUTELY NO WARRANTY.
> >> For details type `warranty'.
> >> Send bug reports to <address@hidden>.
> >> Can not read mailbox
> 
> The problem we are facing is related to locking. Note, that
> mail responds `Can not read mailbox'. This message is issued
> at mail.c:394 and means that mail was able to open the mailbox
> but have failed to scan it.  This is the same problem that I'm
> discussing with Sam at the moment: scanning fails since locker_lock
> is unable to lock the mailbox at mbx_mboxscan.c:577. The problem
> manifests itself in imap4d as well.


I think that's another problem.

Ok, times up. Later.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]