"A month of sundays ago Kari E. Hurtta wrote:"
> Peter T. Breuer:
> > Yes, statting is precisely the problem. Or more accurately, statting
> > all the entries BENEATH all the directories that form initial segments
> > of the path to the system mailbox is the problem.
>
> You claim that.
>
> elm -f xxxx
I have never used the -f option. All my trials have been with plain
"elm" as the commandline call. I don't know why you claim what you claim
I claim above! ;)
> does
> new_browser(..) [see src/init.c]
I have no idea. I think that you will have to _describe_ what it does
in terms more universally communicative than function names. I don't
see why the name "new_browser" should evoke in my mind the concept of
statting every directory BENEATH every directory in the path to
somewhere!
Perhaps I am not getting through to you on this .. I don't care that it
stats things. What I care about is that it stats _irrelevant_ things,
or perhaps stats them at irrelevant moments, because that triggers
irrelevant system events, such as attempted mounts of cdroms and
floppys, blocking both elm and various other aspects of the system (a
mount attempt will take and hold the unique /etc/mtab~ system lockfile
for the duration of the attempt, for example, which is 30s).
Anyway, have we confirmed this? Certainly my strace showed that
originally, and your suggested config file option has cured the
apparently similar behaviour in the newest elm. Does that support the
hypothesis? Remember that my original tests were carried out with an
elm about number -81, if I recall correctly. the most recent one
appears to be -95, and it quite possibly has an entirely different set
of behaviours, as far as I know. I would be grateful if you confined
your analysis to the version that the report was about, as we will make
progress faster that way.
> but without -f option it does
>
> enter_new_folder()
>
> In other words I claim that it is not "the path to the system mailbox".
I have no idea what it is that it is taking the initial segments of the
path of. Does it matter? It seemed from the original straces made to be
the path to $MAIL. Isn't that the "system mailbox"? If I am using the
incorrect term for it, I beg your pardon, but it's not very important
to me what it happens to be termed.
> _Leaving_ of folder does [src/leavembox.c]
>
> struct folder_browser * recv_browser = new_browser(selection_folder);
> struct string * recv_name = new_string(system_charset);
>
> add_ascii_to_string(recv_name,s2us(">")); /* Received folder */
> can_store = select_dir_item(recv_browser,&recv_name);
Is this supposed to mean something? I can assure you that as an
explanation, it fails completely even to communicate itself! Are you
saying that there is in fact a search for some file containing charset
info, and that THAT is what is causing the problem?
If you are saying that, I suggest you "say it". It will make
communication a lot easier. Both ways.
Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
