https://bugzilla.novell.com/show_bug.cgi?id=342075 Mark Gordon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtgordon@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |bk@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 Cyril Hrubis changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |aosthof@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User max@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c5 Reinhard Max changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|seth@iscar.org | Resolution| |NORESPONSE --- Comment #5 from Reinhard Max 2008-09-19 04:20:17 MDT --- No reply for almost two weeks. Please reopen if the problem persists in newer versions. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User seth@iscar.org added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c7 --- Comment #7 from Seth Chaiklin 2008-09-23 06:05:57 MDT --- Will just confirm that the rule that moves the mail to a new folder can also remove the "New" Status. That is, in moving mail to a new folder, the following works. Set New Status = Set Choose One --- -------------------- ( ) Don't change it ( ) Set this state (*) Clear this state but 'Set Delete Status' in the same rule, does not work (even if Set New Status is 'don't change it') (This is still with Alpine 2.00) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User seth@iscar.org added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c9 Seth Chaiklin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED Info Provider|seth@iscar.org | --- Comment #9 from Seth Chaiklin 2008-10-14 11:35:35 MDT --- Sorry -- do not have access to an 11.0 system. The 11.0 OpenSuse Alpine breaks the 10.3 dependencies, hence my use of Dirk's version which is compiled for 10.3 But this should be easy for you to test directly yourself. Make a filter rule in which you move something from the Inbox to a folder, and set Status to Delete. (as shown in Comment #6). You will be able to see instantly if the Status is set or not. All the other Status setting work as expected (see Comment #7), but Delete does not. Note also that it worked properly in pine OpenSuse 10.2, and was broken in the official OpenSUSE 10.3 pine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User chappa@washington.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c11 Eduardo Chappa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chappa@washington.edu --- Comment #11 from Eduardo Chappa 2008-11-09 15:54:54 MST --- (In reply to comment #0 from Seth Chaiklin)

Perhaps this report is meaningless if 'alpine' is the way forward...

I have a filterrule that moves all incoming spam (identified by spamassassin) to a separate inbox. As part of that rule, I have an action to set the status to Delete. That rule has worked without problem for the past year with pine-4.64N-32 (openSuse 10.2).

The rule stopped working after I installed pine-4.64N-93 (openSuse 10.3) -- and started working again after 4.64N-32 was reinstalled.

Correlation is not causation -- but I am inclined to believe that the big patch integration from 21 Sep. has disturbed something.

One more observation. In the same filter rule, I was able to unset the N status, so this is further evidence that the rule can change status. But for some reason, it will not change status to Delete.

I have read this report and I still fail to see the bug. I need data to reproduce the problem. Here is what I understand from the report. * That a rule to move a message to another folder and set its status to deleted is not working. I understand that setting the delete status would be done in the target folder, not in the source folder (Pine sets the delete status in the source folder anyway). * I have tried a rule like this in a pine patched will all.patch and with no other patches and the rule works. That is, the message in the target folder is marked deleted. This is not to say that there is no problem in all.patch. I am just saying that there is not enough evidence to check that the problem exists in all.patch. For all I know the problem might be in another patch added by SuSe. In order to determine this, we need to make a few more tests and gather more information. * I need a copy of the .pinerc file that is read by pine when the problem is produced. This I need because at this moment it is possible that the problem be in all.patch but it is reproduced by settings that I do not have set. * If you are not willing to give me a copy of the .pinerc, I need to know if this problem is produced through IMAP, POP, etc. Server names are good, because I can try to test them. Settings are good because I can see how they get together to reproduce the problem. * If you are not going through IMAP, are you using maildir at all? I do remember that there was a change in all.patch between the versions that are mentioned here, but that change had to do with a change in the fillpara patch (see my web page for more details on what this patch does), and no code in all.patch had anything to do with filtering, so I find all of these problems very unlikely to have been caused by all.patch, but since we don't know, I am willing to investigate, and fix any problems in all.patch, if any. What I am saying here is that if the problem had existed in all.patch in version 10.2, it would have probably existed in 10.3. I would also try to see if there are other changed that were added by Bernhard other than mine. Another thing to look into is to see if the integration of patches was done properly. This is something that only Bernhard could have done. There may be a patch that was added incorrectly. Since I can not reproduce the problem at all, less at will, I am asking for real data that shows the problem. I would be really interested to see this to determine where the problem comes from. Thank you. -- Eduardo http://staff.washington.edu/chappa/pine/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User max@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c13 Reinhard Max changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |seth@iscar.org --- Comment #13 from Reinhard Max 2008-11-10 02:04:24 MST --- (In reply to comment #12 from Reinhard Max)

In Comment #2 Seth says, [...]

Whoops, meant to say in comment #1. (In reply to comment #11 from Eduardo Chappa)

What I am saying here is that if the problem had existed in all.patch in version 10.2, it would have probably existed in 10.3.

So, you were trying it with all.patch from 10.2? If I got Seth correctly, 10.2 and previous versions were working fine for him and the problem appeared in 10.3. Setting NEEDINFO for the remaining questions from comment #11. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User max@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c15 --- Comment #15 from Reinhard Max 2008-11-10 16:51:00 MST --- (In reply to comment #14 from Eduardo Chappa)

I downloaded pine-4.64N-93 from the web and installed it, and I got the problem to produce a saved message that is not marked "D" in the target folder. I believe this is the problem that the original poster is referring to.

Now I am completely confused. You say you cannot produce a message that is *not* marked "D", but Seth's bug report was that he cannot produce a message that *is* marked "D". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User chappa@washington.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c17 --- Comment #17 from Eduardo Chappa 2008-11-11 00:01:07 MST --- (In reply to comment #16 from Eduardo Chappa)

That's the point. This depends on a setting in Pine that I need information on.

Ok, I think I found a reliable way to reproduce the problem. I need confirmation that this is the case. In this case, the problem is in Pine4.64 and all versions of Alpine. Here is the basic situation. A filter is set to save a message and the Delete flag is set, as explained before. This should cause the Delete flag to be set in the saved message in the target folder. Here is what I found: If the target folder is accessed through IMAP, then the message filtered is marked deleted in the target folder. However, if the target folder is accessed locally, then the filtered message is not marked deleted in the target folder. What I believe that Seth is reporting is that when he upgrades, he notices these changes because in some cases he changes his configurations/ways to access folders. Sometimes they are local (and they fail) and sometimes they are remote (and they succeed). Is this correct? If the answer is yes, then the problem is not in all.patch, but in raw pine/alpine. Anyone can check this in raw Alpine. If so, then I have a patch for this, which I will add to all.patch very soon. -- Eduardo http://staff.washington.edu/chappa/pine/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=342075 User chappa@washington.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=342075#c19 --- Comment #19 from Eduardo Chappa 2008-11-11 11:19:59 MST --- (In reply to comment #18 from Seth Chaiklin)

No. This was not related to IMAP. In this particular case I was not using IMAP.

Excellent, this, and other things you send, are exactly what I needed to know. The problem you have is a problem with Alpine. I have tried the same configuration in unpatched alpine at I see the bug. Have you tried that? If not, please confirm this. What I am trying to say, is that this is a bug in Alpine, not in all.patch. But why do you see the problem in all.patch? Well that's a longer explanation, but here it goes. There are big differences between the patches in 10.2 and 10.3. More that I could remember. I remember that the reason why Bernhard upgraded the patch was because of a bug in the fillpara patch. However, between the released all.patch that Bernhard used for 10.2 and the one he used for 10.3, there were more differences than that. In particular, there was a patch by Steve Hubert (of the Pine team at the time), that made Pine preserve the order of messages when an aggregate save was done between folders of different formats. <technical part> This part had to do with streams. In particular, setting the stream of the target. Before this change, pine set the stream of the target to be the stream of the source, but with the change it set it to NULL. Due to this, an essential part of the code that sets the DELETED flag in the target folder is not executed. Hence the bug. That same code became part of Alpine, so the same problem exists in Alpine. I will try to look for a solution that sets the deleted flag in the same way that was done in 10.2, but in the mean time, there is a way to overcome this problem (for Alpine), through a new patch in my page (address below). That patch works because it sets the deleted flag on the message in the target folder, since that other part of the code that needs the save_stream does not have one. I hope that this makes sense. Reinhard, does it make sense to backport a fix to Pine 4.64 or are you moving away from Pine? -- Eduardo http://staff.washington.edu/chappa/alpine/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.