courier-cone — Cone mail client mailing list.

Re: [cone] Automatic refresh for local Maildir's mail counts -- an attempt based on named pipes

[Linux-Fan <Ma_...@we...>]

Sam Varshavchik writes:

> Linux-Fan writes:
>
>> The attached patch thus implements polling in an own location which
>> means it only happens every `mailCheckInterval` (worst case: 300)
>> seconds.
>>
>> My questions are now as follows:
>>
>> * Is the idea implemented by the attached patch safe enough to be
>>   included in Cone?
>
> The general idea is correct.
>
>> * What can I do to have the polling mechanism which is already in
>>   use in Cone also poll my named pipe file descriptor such that mail
>>   counts are immediately updated?
>
> I think all you need to do is add your named pipe's descriptor to the fds  
> vector, that gets passed to poll(). This will include the named pipe in the  
> list of file descriptor that gets monitored, by the main event loop.

Thank you very much for the explanation.
 
The actual error (why I initially got endless loops when trying to do this),  
was with my understanding of named pipes: What actually caused the endless  
loop was that whenever I notified Cone from offlineimap, the named pipe got  
closed in the process, causing POLLHUP to be returned (immediately) on all  
subsequent poll invocations.

I have now fixed this by re-opening the file descriptor once POLLHUP is  
returned and now it works as expected. See attached  
`patch_cone_refresh_with_named_pipe_2.diff`.

Yours Faithfully
Linux-Fan

Re: [cone] Automatic refresh for local Maildir's mail counts -- an attempt based on named pipes

[Sam V. <mr...@co...>]

Linux-Fan writes:

> The attached patch thus implements polling in an own location which
> means it only happens every `mailCheckInterval` (worst case: 300)
> seconds.
>
> My questions are now as follows:
>
> * Is the idea implemented by the attached patch safe enough to be
>   included in Cone?

The general idea is correct.

> * What can I do to have the polling mechanism which is already in
>   use in Cone also poll my named pipe file descriptor such that mail
>   counts are immediately updated?

I think all you need to do is add your named pipe's descriptor to the fds  
vector, that gets passed to poll(). This will include the named pipe in the  
list of file descriptor that gets monitored, by the main event loop.

[cone] Automatic refresh for local Maildir's mail counts -- an attempt based on named pipes

[Linux-Fan <Ma_...@we...>]

Dear Mr. Varshavchik, dear other Cone users,

it has been more than a year since I wrote about means to automatically
refresh Maildir's displayed mail counts
(https://sourceforge.net/p/courier/mailman/message/35577227/).

I have been running the patch proposed there ever since and it worked.
Still, during a discussion with a friend, I got convinced that signals
and multithreaded programs should really be avoided as much as possible.

As a result, I have thought of another way to interact with Cone for
triggering a refresh of mail counts and ended up with an approach based
on named pipes.

Unlike before, a write to the named pipe does not interrupt Cone and
is thus much safer.

However, I did not manage to have the named pipe polled at the same
location as other poll calls in Cone happen, because this always
resulted in either my file descriptor being ignored (when calling
`fds.push_back(myServer::pollFDForRefreshMessageCount)` in
myserver.C:192 only) or in an endless loop (when calling `push_back`
also in line 239 in the same file).

The attached patch thus implements polling in an own location which
means it only happens every `mailCheckInterval` (worst case: 300)
seconds.

My questions are now as follows:

 * Is the idea implemented by the attached patch safe enough to be
   included in Cone?

 * What can I do to have the polling mechanism which is already in
   use in Cone also poll my named pipe file descriptor such that mail
   counts are immediately updated?

Thanks in advance and Yours Sincerely
Linux-Fan

[cone] Courier build 20180216

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.html


Changes:

• reformime: -rU option.

• reformime: fix crash due to an invalid -s option

• maildirmake: the -q option creates a new maildir if it does not exist.

• courier/courier-imap/cone: couriertls: GnuTLS: remove usage of deprecated  
OpenPGP API. Adjust error logging to include the peer's IP address, where  
available.

• maildrop: new :H pattern option matches only the main message headers,  
does not match headers in the message's attachments, if any.

[cone] New releases of courier, sqwebmail, maildrop, and cone

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.html

Changes:

• courier: use libtool to build libfilter and waitlib libraries, this fixes  
a linking failure on Fedora 27. Other fixes to the rpm packaging.

• gettext library update.

• Fixes a null pointer dereference that may happen when creating a reply  
message. The fixed code is used by the mailbot command line tool, also  
sqwebmail, and cone.

• Cone: switch from iso-8859-1 to utf-8 for interpreting unencoded text in  
mail headers.

[cone] New releases of courier, courier-imap, maildrop, and cone packages

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.html

Changes:

- courier: the SMTP sending code has been rewritten and factored out into an  
internal library.

- courier: new "verifyfilter" module, a filter module that verifies the  
email sender address by initiating a callback connection to the sender's  
domain, using the internal SMTP library. The module is also available as a  
"verifysmtp" command-line tool, that does the same.

- maildrop: added the new "system" command.

- courier, courier-imap, cone: OpenSSL 1.1.0 update. Some options to select  
specific TLS protocol levels are no longer available. The TLS_PROTOCOL  
setting adjusted accordingly, and the deprecated options are mapped to their  
nearest approximate setting. No changes to the GnuTLS alternative option.

[cone] Build 20170309 of Courier packages

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.html

New builds of courier-unicode, courier, courier-imap, sqwebmail, maildrop,  
and cone packages.

• A few more tweaks to the courier-unicode configuration script.

• All other packages are rebuilt against the new courier-unicode package,  
and require the new version for building, going forward.

• courier: switched blacklist lookups to use either TXT or A records instead  
of ANY, depending on the blacklist setting; documentation updated  
accordingly.

[cone] courier-unicode build 20170308 released

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.php#unicode

Revised configuration script to enable C++11 builds that should work with  
older versions of gcc.

[cone] courier unicode build 20170306

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.html#unicode

This is a test build of the courier-unicode package, that uses C++11's  
unicode support. Please report any build issues to the courier-users list.

Re: [cone] Poll: C++11 compiler support

[Roel v. M. <ro...@ls...>]

Sam Varshavchik writes:

> ...
> I am taking a poll whether there's still any notable platforms where  
> Courier and Cone is used that's still using an old compiler that does not  
> support C++11.
> ...

Hi Sam,

all of the systems that I use cone on (Slackware, Debian) are recent enough  
that they support C++11. I would not be inconvenienced if you would start  
requiring C++11's unicode support.

Thanks,

Roel

Re: [cone] Poll: C++11 compiler support

[Nux! <nu...@li...>]

Hello,

Yep, that worked. No errors whatsoever.


g++ -std=c++0x -o utest utest.C

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Sam Varshavchik" <mr...@co...>
> To: "courier-users" <cou...@li...>, "courier-cone" <cou...@li...>
> Sent: Monday, 6 March, 2017 11:58:54
> Subject: Re: [cone] Poll: C++11 compiler support

> Nux! writes:
> 
>> Hello,
>>
>> Got errors with both commands:
>> CentOS 6 x86_64, gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
>>
>> This could have some impact as CentOS 6 is still pretty used in the server
>> world.
>>
>> g++ -o utest utest.C
>> utest.C: In function ‘int main()’:
>> utest.C:5: error: ‘char32_t’ was not declared in this scope
>> utest.C:5: error: expected ‘;’ before ‘c’
>> utest.C:6: error: ‘u32string’ is not a member of ‘std’
>> utest.C:6: error: expected ‘;’ before ‘u’
>>
>> g++ -std=c++11 -o utest utest.C
>> cc1plus: error: unrecognized command line option "-std=c++11"
> 
> Ok, now try:
> 
> g++ -std=c++0x -o utest utest.C
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Courier-cone mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-cone

Re: [cone] Poll: C++11 compiler support

[Sam V. <mr...@co...>]

Nux! writes:

> Hello,
>
> Got errors with both commands:
> CentOS 6 x86_64, gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
>
> This could have some impact as CentOS 6 is still pretty used in the server  
> world.
>
> g++ -o utest utest.C
> utest.C: In function ‘int main()’:
> utest.C:5: error: ‘char32_t’ was not declared in this scope
> utest.C:5: error: expected ‘;’ before ‘c’
> utest.C:6: error: ‘u32string’ is not a member of ‘std’
> utest.C:6: error: expected ‘;’ before ‘u’
>
> g++ -std=c++11 -o utest utest.C
> cc1plus: error: unrecognized command line option "-std=c++11"

Ok, now try:

g++ -std=c++0x -o utest utest.C

Re: [cone] Poll: C++11 compiler support

[Nux! <nu...@li...>]

Hello,

Got errors with both commands:
CentOS 6 x86_64, gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)

This could have some impact as CentOS 6 is still pretty used in the server world.

g++ -o utest utest.C
utest.C: In function ‘int main()’:
utest.C:5: error: ‘char32_t’ was not declared in this scope
utest.C:5: error: expected ‘;’ before ‘c’
utest.C:6: error: ‘u32string’ is not a member of ‘std’
utest.C:6: error: expected ‘;’ before ‘u’

g++ -std=c++11 -o utest utest.C
cc1plus: error: unrecognized command line option "-std=c++11"

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Sam Varshavchik" <mr...@co...>
> To: cou...@li..., cou...@li..., cou...@li...,
> "SqWebMail mailing list" <cou...@li...>, "Maildrop mailing list"
> <cou...@li...>, cou...@li...
> Sent: Sunday, 5 March, 2017 20:21:43
> Subject: [cone] Poll: C++11 compiler support

> The forward match of progress is requiring a clean break from the pre-c++11
> days. Under consideration is migrating the courier-unicode library, used by
> both Courier and Cone, to use C++11's unicode support only.
> 
> I am taking a poll whether there's still any notable platforms where Courier
> and Cone is used that's still using an old compiler that does not support
> C++11.
> 
> According to gcc's documentation, gcc 4.8.1 was the first version with full
> C++11 support; but it's likely that older versions of gcc had sufficient
> support. gcc 4.5's compliance page gives Unicode string literals as
> supported, so I'm fairly confident of sufficient C++11 unicode support at
> least in gcc 4.5, at the latest.
> 
> I'd like to know if your compiler does not support C++11 unicode strings.
> This can be determined with a simple test:
> 
> #include <string>
> 
> int main()
> {
>    char32_t c=0;
>    std::u32string u;
> 
>    return 0;
> }
> 
> Save the above as "utest.C", then execute either:
> 
> g++ -o utest utest.C
> 
> or
> 
> g++ -std=c++11 -o utest utest.C
> 
> If either one completes without errors, you're good. This is if your
> compiler is "g++", of course. Certain platforms, like Debian, FreeBSD, and
> many others, might have multiple versions of gcc installed; typically as
> "g++NN". Use the appropriate command for your gcc.
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Courier-cone mailing list
> Cou...@li...
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-cone

[cone] Cone 0.95 released

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.php#imap

Changes:

* Improve compatibility with current versions of OpenSSL, and GnuPG 2

* Fixed a bug that skipped messages on some Usenet servers

[cone] Poll: C++11 compiler support

[Sam V. <mr...@co...>]

The forward match of progress is requiring a clean break from the pre-c++11  
days. Under consideration is migrating the courier-unicode library, used by  
both Courier and Cone, to use C++11's unicode support only.

I am taking a poll whether there's still any notable platforms where Courier  
and Cone is used that's still using an old compiler that does not support  
C++11.

According to gcc's documentation, gcc 4.8.1 was the first version with full  
C++11 support; but it's likely that older versions of gcc had sufficient  
support. gcc 4.5's compliance page gives Unicode string literals as  
supported, so I'm fairly confident of sufficient C++11 unicode support at  
least in gcc 4.5, at the latest.

I'd like to know if your compiler does not support C++11 unicode strings.  
This can be determined with a simple test:

#include <string>

int main()
{
    char32_t c=0;
    std::u32string u;

    return 0;
}

Save the above as "utest.C", then execute either:

g++ -o utest utest.C

or

g++ -std=c++11 -o utest utest.C

If either one completes without errors, you're good. This is if your  
compiler is "g++", of course. Certain platforms, like Debian, FreeBSD, and  
many others, might have multiple versions of gcc installed; typically as  
"g++NN". Use the appropriate command for your gcc.

[cone] Development builds of courier, courier-imap, and cone packages

[Sam V. <mr...@co...>]

Download: http://www.courier-mta.org/download.html

courier, courier-imap, and cone builds 20170218:

Changes:

- Fix compilation errors with OpenSSL 1.1.0

Re: [cone] Automatic Refresh for local Maildir's mail counts

[Sam V. <mr...@co...>]

Linux-Fan writes:

> OK. I have changed the code to no longer rely on an atomic primitive. I
> have implemented this by maintaining two counters where the first one
> counts the number of signals received and the second one counts the
> number of signals processed. This way, there is no potential for losing
> a signal as there are no concurrent writes to the variables. (Well,
> theoretically signals may still get lost: If exactly 2^32 signals are
> received before Cone runs the function to detect pending updates, there
> will not be an update, because advancing the counter 2^32 times puts it
> back to it's initial position)

There is a reason why sig_atomic_t exists. The problem with sig_atomic_t is  
that it's unavailable on older platforms. There, platform-specific types  
were typically used for this purpose.

> I have not tried to do it with pipes because I find them more complex:
> Pipes need to be opened explicitely and I have not found a definite
> answer about the question whether POSIX specifies writing to a pipe
> from inside a signal handler to behave well-defined.

The write() system call is explicitly listed as being safe to call from a  
signal handler, see signal(7).

> Also, I am not sure (for the pipe-idea) what happens if for any reason,
> a lot of signals are received: My current solution will just keep

I believe I already pointed you to using non-blocking mode, for both writing  
and reading from the pipe. Once something is read from the pipe, loop and  
keep reading from it until it is completely drained.

This is, of course, entirely up to you. I'm just pointing out the direction  
I would've gone, in the same situation.

Re: [cone] Automatic Refresh for local Maildir's mail counts

[Linux-Fan <Ma_...@we...>]

[Wed, 01 Feb 2017 21:44:39 -0500] Sam Varshavchik
<mr...@co...> wrote:
> Linux-Fan writes:
> 
> > It is not using a pipe, but a C++11 std::atomic instead. If that
> > cannot be used, because Cone needs to compile without C++11 (I used
> > `./configure CPPFLAGS=-std=c++11` to get it to work), I'd replace
> > this by a variable which is marked `volatile sig_atomic_t`.
> 
> Cone is still compiled on relatively old platforms. C++11 is not a
> viable option right now; but probably in a little while this would be
> an option.

OK. I have changed the code to no longer rely on an atomic primitive. I
have implemented this by maintaining two counters where the first one
counts the number of signals received and the second one counts the
number of signals processed. This way, there is no potential for losing
a signal as there are no concurrent writes to the variables. (Well,
theoretically signals may still get lost: If exactly 2^32 signals are
received before Cone runs the function to detect pending updates, there
will not be an update, because advancing the counter 2^32 times puts it
back to it's initial position)

> I do not see a good reason not to use an internal pipe, in
> non-blocking mode, and with O_CLOEXEC set.

I have not tried to do it with pipes because I find them more complex:
Pipes need to be opened explicitely and I have not found a definite
answer about the question whether POSIX specifies writing to a pipe
from inside a signal handler to behave well-defined.

Also, I am not sure (for the pipe-idea) what happens if for any reason,
a lot of signals are received: My current solution will just keep
updating the messages all the times it is polled by the event loop.
Whenever a flood of signals stops, it will also do at most one update
after that. If I were to implement a pipe to detect signals, the pipe
would be filled (completely) whenever a flood of signals arises. On the
other end, my implementation should attempt to read as many entries as
possible (at once) from the pipe in order not to keep updating multiple
times even though the time the update was necessary is long in the
past. It might introduce a potential for nontermination if one end of
the pipe is continuously populated by signals while the other end is
continuously read (but never empty as for a steady stream of arriving
signals)...

All in all, I find pipes harder to reason about and thus went for the
easiest solution: Initially one atomic integer and now: two integers.

> sig_atomic_t has been around only since C99; but I suppose at this
> time requiring C99 would be acceptable.

Additionally, it should be available on every POSIX-compatible system.
This time, no additional options to `configure` were needed.

[...]

> No big rush here. You can take your time and test your changes
> thoroughly. In general, this looks fine but I have not had a closer
> look; but I will consider it. A few procedural things will need to
> happen for that; but that can be left for later...

Very well. I shall test this in practice :)

Thank you for the constructive reply :)

Yours Sincerely
Linux-Fan

-- 
http://masysma.lima-city.de/

Re: [cone] Automatic Refresh for local Maildir's mail counts

[Sam V. <mr...@co...>]

Linux-Fan writes:

> It is not using a pipe, but a C++11 std::atomic instead. If that cannot
> be used, because Cone needs to compile without C++11 (I used
> `./configure CPPFLAGS=-std=c++11` to get it to work), I'd replace this
> by a variable which is marked `volatile sig_atomic_t`.

Cone is still compiled on relatively old platforms. C++11 is not a viable  
option right now; but probably in a little while this would be an option.

I do not see a good reason not to use an internal pipe, in non-blocking  
mode, and with O_CLOEXEC set. sig_atomic_t has been around only since C99;  
but I suppose at this time requiring C99 would be acceptable.

> What do you think? Does it make sense to put it that way or have I
> misplaced the call to `processHierharcyRefresh()`? Is it better to use
> `SA_RESTART` or not? I am not quite sure...
> Also, in order to improve the folder refreshing mechanism, I have
> implemented a `RefreshIterator` which uses `updateInfo` on all folder
> entries. Have I used the API correctly?

I would have to look at this closer, to determine the right answer.

> By the way: If you wonder about the `masysma` prefixes and annotations:
> I will happily remove these if the patch has a chance of being
> incorporated but for now I have added them to easily navigate to my
> modifications within the code and make sure I do not confuse my
> changes with what was already there...

No big rush here. You can take your time and test your changes thoroughly.  
In general, this looks fine but I have not had a closer look; but I will  
consider it. A few procedural things will need to happen for that; but that  
can be left for later...

Re: [cone] Automatic Refresh for local Maildir's mail counts

[Linux-Fan <Ma_...@we...>]

[Sun, 1 Jan 2017 23:15:02 +0100] Linux-Fan <Ma_...@we...> wrote:
> [Sat, 31 Dec 2016 12:27:38 -0500] Sam Varshavchik
> <mr...@co...> wrote:
> > Linux-Fan writes:

[...]

> > > Is it possible/planned to add a means of updating the message
> > > counts from the folder hierarchy view automatically as well
> > > (similar to what I did upon receiving a SIGUSR1 for my
> > > proof-of-concept patch from the previous mail)?
> > 
> > I'm open to such a feature; however this approach won't work.
> > Signals
> 
> [...]
> 
> > The only safe way to do this: in addition to installing a signal
> > handler, an internal pipe needs to be created, and put into
> > nonblocking mode. The only thing the signal handler does is write a
> > byte to the pipe, ignoring the results, and immediately terminating.
> > 
> > Then, on the folder screen only, in addition to handling all the
> > regular events the read end of the pipe gets polled as well, and
> > when something is read, what your patch does would happen.
> 
> OK. I am going to check this out when I find time to dig into the
> source code again :)

[...]

I have taken on the challenge and tried to create a (more) correct
patch which enables cone-0.92 to update all folder's message counts
upon receiving a SIGUSR1.

It is not using a pipe, but a C++11 std::atomic instead. If that cannot
be used, because Cone needs to compile without C++11 (I used
`./configure CPPFLAGS=-std=c++11` to get it to work), I'd replace this
by a variable which is marked `volatile sig_atomic_t`.

What do you think? Does it make sense to put it that way or have I
misplaced the call to `processHierharcyRefresh()`? Is it better to use
`SA_RESTART` or not? I am not quite sure...
Also, in order to improve the folder refreshing mechanism, I have
implemented a `RefreshIterator` which uses `updateInfo` on all folder
entries. Have I used the API correctly?

> > Even with that, things may not work 100%. All the code needs to be
> > audited and verified that it'll correctly handle an interrupted
> > system call.
> >
> > Correct signal handling is hard.  
> 
> Yes it is :( Especially signal handling from within multithreaded
> applications is probably asking for trouble, so I understand that
> might not be the best solution here...

If signal handling is still too much of an issue with regard to the
overall application stability, might it make sense to replace my check
for `pendingUpdates.exchange(0) > 0` with a simple timer
(like if now - lastTimeOfCheck > NN seconds refresh)?

By the way: If you wonder about the `masysma` prefixes and annotations:
I will happily remove these if the patch has a chance of being
incorporated but for now I have added them to easily navigate to my
modifications within the code and make sure I do not confuse my
changes with what was already there...

Yours Sincerely and TIA
Linux-Fan

-- 
http://masysma.lima-city.de/

Re: [cone] Automatic Refresh for local Maildir's mail counts?

[Linux-Fan <Ma_...@we...>]

[Sat, 31 Dec 2016 12:27:38 -0500] Sam Varshavchik
<mr...@co...> wrote:
> Linux-Fan writes:
> 
> > > If you do not have a folder open, but looking at the folder
> > > hierarchy, the message counts are not going to get updated in
> > > realtime. There's no facility to do that.

[...]

> > Is it possible/planned to add a means of updating the message counts
> > from the folder hierarchy view automatically as well (similar to
> > what I did upon receiving a SIGUSR1 for my proof-of-concept patch
> > from the previous mail)?
> 
> I'm open to such a feature; however this approach won't work. Signals

[...]

> The only safe way to do this: in addition to installing a signal
> handler, an internal pipe needs to be created, and put into
> nonblocking mode. The only thing the signal handler does is write a
> byte to the pipe, ignoring the results, and immediately terminating.
> 
> Then, on the folder screen only, in addition to handling all the
> regular events the read end of the pipe gets polled as well, and when
> something is read, what your patch does would happen.

OK. I am going to check this out when I find time to dig into the
source code again :) How about the other option: Just extending the (as
far as I understand it) existing event polling to also check for new
messages every NN seconds or such? I do not like polling that much but
in this case it sounds easier and probably more reliable?

> Even with that, things may not work 100%. All the code needs to be
> audited and verified that it'll correctly handle an interrupted
> system call.
>
> Correct signal handling is hard.

Yes it is :( Especially signal handling from within multithreaded
applications is probably asking for trouble, so I understand that might
not be the best solution here...

Thank you for the quick and thorough reply, I really appreciate it.

Happy new year to all list members :) !

Yours Sincerely
Linux-Fan

-- 
http://masysma.lima-city.de/

Re: [cone] Automatic Refresh for local Maildir's mail counts?

[Sam V. <mr...@co...>]

Linux-Fan writes:

> > If you do not have a folder open, but looking at the folder
> > hierarchy, the message counts are not going to get updated in
> > realtime. There's no facility to do that.
>
> Ah OK, that's it: I misunderstood the meaning of ``open'' thinking it
> was enough to view the folder hierarchy instead of looking at the actual
> folder contents. The updates for the folder currently opened in a sense
> that the contents are displayed work well (see above).
>
> Is it possible/planned to add a means of updating the message counts
> from the folder hierarchy view automatically as well (similar to what
> I did upon receiving a SIGUSR1 for my proof-of-concept patch from the
> previous mail)?

I'm open to such a feature; however this approach won't work. Signals are  
asynchronous, and none of the high levels function that the handler invokes  
are async-safe. If cone is doing nothing but polling for the next event,  
it'll work fine. If cone is in the middle of something, there's a high  
likelyhood of a crash. And if cone is not displaying the folder hierarchy,  
this is pretty much a guaranteed crash.

The only safe way to do this: in addition to installing a signal handler, an  
internal pipe needs to be created, and put into nonblocking mode. The only  
thing the signal handler does is write a byte to the pipe, ignoring the  
results, and immediately terminating.

Then, on the folder screen only, in addition to handling all the regular  
events the read end of the pipe gets polled as well, and when something is  
read, what your patch does would happen.

Even with that, things may not work 100%. All the code needs to be audited  
and verified that it'll correctly handle an interrupted system call.

Correct signal handling is hard.

Re: [cone] Automatic Refresh for local Maildir's mail counts?

[Linux-Fan <Ma_...@we...>]

[Sat, 31 Dec 2016 10:23:26 -0500] Sam Varshavchik
<mr...@co...> wrote:
> Linux-Fan writes:
> 
> > Now in order for this to work as I expect it, Cone needs to
> > automatically update the e-mail counts from local Maildirs to
> > display the changes made externally via Offlineimap and the
> > filtering tool.
> 
> This should happen automatically already.
> 
> If you have a local maildir open, a new message delivered there
> should result in the display immediately updated (well, within a few
> seconds).
> 
> > As far as I understand, there is an option called `/noop=N` [2] to
> > poll IMAP accounts. I tried to use that (testing with an IMAP
> > account),
> 
> IMAP and local maildirs have nothing to do with each other.
> 
> If the IMAP server supports IDLE, and an IMAP folder is open, a new
> message in the IMAP folder will also result in an immediate refresh.

Just for the record: I have tested it with viewing the folder contents
in Cone and it works just as described above for IMAP and local
Maildirs.

> If you do not have a folder open, but looking at the folder
> hierarchy, the message counts are not going to get updated in
> realtime. There's no facility to do that.

Ah OK, that's it: I misunderstood the meaning of ``open'' thinking it
was enough to view the folder hierarchy instead of looking at the actual
folder contents. The updates for the folder currently opened in a sense
that the contents are displayed work well (see above).

Is it possible/planned to add a means of updating the message counts
from the folder hierarchy view automatically as well (similar to what
I did upon receiving a SIGUSR1 for my proof-of-concept patch from the
previous mail)?

TIA and Yours Sincerely
Linux-Fan

-- 
http://masysma.lima-city.de/

Re: [cone] Automatic Refresh for local Maildir's mail counts?

[Sam V. <mr...@co...>]

Linux-Fan writes:

> Now in order for this to work as I expect it, Cone needs to
> automatically update the e-mail counts from local Maildirs to display
> the changes made externally via Offlineimap and the filtering tool.

This should happen automatically already.

If you have a local maildir open, a new message delivered there should  
result in the display immediately updated (well, within a few seconds).

> As far as I understand, there is an option called `/noop=N` [2] to
> poll IMAP accounts. I tried to use that (testing with an IMAP account),

IMAP and local maildirs have nothing to do with each other.

If the IMAP server supports IDLE, and an IMAP folder is open, a new message  
in the IMAP folder will also result in an immediate refresh.

If you do not have a folder open, but looking at the folder hierarchy,  
the message counts are not going to get updated in realtime. There's no  
facility to do that.

[cone] Automatic Refresh for local Maildir's mail counts?

[Linux-Fan <Ma_...@we...>]

Dear Cone users,

In [1] I asked if it might be possible to add a means of filtering
accross account boundaries to Cone in order to be able to replicate
my mail setup with it. I have understood it does not work that way
because moving across accounts is conceptually different from moving
inside the same account.

Still, I have not given up on trying to configure Cone in a way I could
use it as my mail client: While I did not try to amend Cone's filtering
system to work across server boundaries, I have thought of another
solution to the problem: In order to have filtering across account
boundaries, I could use an external program to process incoming e-mails
and then only read (and write) them in Cone.

The setup is intended to look something like this

  Offlineimap               Filtering tool¹        Cone
  ---------------------     ------------------     ---------------------
  Downloads mails and   --> Moves mails inside --> Is used to read from
  uploads changes to an     a local Maildir        the local Maildir and
  IMAP Server               structure              send via SMTP.

Now in order for this to work as I expect it, Cone needs to
automatically update the e-mail counts from local Maildirs to display
the changes made externally via Offlineimap and the filtering tool.

As far as I understand, there is an option called `/noop=N` [2] to
poll IMAP accounts. I tried to use that (testing with an IMAP account),
but it did not automatically tell me `... unread` after receiving a new
mail until I opened and closed the folder again?

Alternatively, I have tried to implement a refresh via a `SIGUSR1` to
Cone by collapsing and expanding the currently selected subtree. This is
a hack and while it does something similar to what I want (if the
correct entry is selected, it refreshes the mail counters), it does not
do it right: It depends on the current selection and it marks all
folders (as if they were highlighted by the cursor) for reasons unknown
to me :)

Now my question is: Is there a recommended way to achieve automatic
updating of (new-)mail counters for offline accounts / e-mail data
processed by a separate tool? If not, is there a chance of getting the
`/noop=N` thing to work with local Maildirs making it update
e-mail counts without interaction or is there a chance of implementing a
`SIGUSR1` to refresh in a more sensible way than I did?

In order to illustrate what I am thinking about, I have attached my
patch to enhance cone-0.92 with a hacky `SIGUSR1` support. If you think
it might be a good idea to rewrite the patch to apply to the newest
Cone version, I will try to do that. However, I do not think that
my hack is the way to go with respect to the issue I want to solve.

¹) I do not know which filtering tool to use, yet.

TIA and Yours Sincerely
Linux-Fan

[1] https://sourceforge.net/p/courier/mailman/message/35086282/
[2] http://www.courier-mta.org/cone/cone06newaccount.html

-- 
http://masysma.lima-city.de/