[Alpine-info] Re: [Append of zero-length message] error in NNTP

[Joe(theWordy)Philbrook]

It would appear that on Feb 6, Eduardo Chappa did say:


> On Sat, 4 Feb 2012, Joe(theWordy)Philbrook wrote:

> 

> :) I wasn't sure if this was an alpine issue or something about the 

> :) newsgroup where I've been encountering this error, So I started there, 

> :) for details please see:

> :) 

> :) http://thread.gmane.org/gmane.discuss/14660

> 

> I see your problem. A summary of your problems is as follows: you save 

> messages using a filter, but when you get to expired messages Alpine fails 

> to save messages.

> 

> First, when the store is NNTP, a server is allowed to advertise messages 

> that have expired. This is normal, however, Alpine does not handle this 

> gracefully when it is *saving*.


In a nutshell that sounds like the problem. Though why this only seems to
happen with this one group, and why it's only been happening often enough
for me to slow down & look close enough to see the error message for the
past month or so. But that for years, it either didn't happen or didn't
happen often enough for me to notice, is beyond my understanding...
 

> Unfortunately, Alpine thinks that saving between any two stores is an 

> atomic operation (it has to complete successfully or fail completely). 

> While this is nice (because you never have to worry if all messages were 

> transfered once the command ended successfully), it also has some 

> problems, as in "a save 500 messages can fail because message 499 was not 

> fetched". There is no "partial save" feature, which would be extremely 

> useful in general.


Yes that would be wonderful. Especially for when done via the filter rule
that says to "move" the messages. I wouldn't even mind if it effectively
saved a blank {dummy} message perhaps with a dummy content equal to what
the error message would have been when I tried to read the bad message.


> To me, Alpine is good at reading messages, but saving is not the best. 

> Considering saving an atomic operation under all circumstances is not 

> quite right, there should be middle ground, a process that lets you review 

> the current changes to be done and predict what will happen in the event 

> you accept those changes, but not unilaterally fail the operation.

> 

> This is in my todo list now.


Perhaps it could allow for either a basic configuration or better yet a "per
filter rule" action setting to allow "skipping" "unfetchable" messages.
Possibly with a sub option setting to delete {exclude} any such skipped
messages??

-- 

|  ~^~   ~^~

|  <?>   <?>       Joe (theWordy) Philbrook

|      ^                J(tWdy)P

|    \___/         <<jtwdyp at ttlc.net>>