On Wed, 2003-02-26 at 23:52, Not Zed wrote: > On Thu, 2003-02-27 at 10:16, Jeffrey Stedfast wrote: > > did some digging and it seems that my first impression of the problem > > was *almost right*. I had been thinking that we were passing the last > > \n before the boundary (which really belongs to the boundary, so we > > should not be doing that) but it actually turns out the canon filter > > code would always just add a \r\n to the end of the stream even if the > > higher-level code did provided a stream that did not end with \n > > > > however, that was not the only problem... I discovered in my testing > > that the code was in fact dropping the entire last line when sending it > > to gpg because the last line did not end with a \n, and so it was saved > > in the backup buffer of the canon filter waiting for a > > filter_complete(). > > > > the filter_complete(), however, would never come because: > > 1) all of the data had been read from the src stream > > 2) filter_stream->priv->filteredlen == 0, meaning that the filter_stream > > did not have any data in its own buffer. > > > to fix this, I just fixed camel-stream-filter.c:do_eos() to check for > > buffered data in any of the filters in the chain. if there was data > > there, then eos == FALSE. > > I'm not sure this fix is correct, but it might be, i'll verify. > > Another simpler way might be to do > > eos = filteredlen == 0 > && complete has been called > > and set the 'complete called' when its been called, since filters MUST > flush everything when that is called.
that'd be fine... > > > attached are patches for 1.2 and 1.3 - it seems when I backported a > > patch from 1.3 to 1.2 (or vise versa?) and extra blank line made it in > > there and so the 1.3 patch will not apply cleanly to the 1-2-branch, so > > I made 2 patches. both are identical except for that minor difference. > > > > Michael (NotZed): The only change I'm not 100% sure about is the removal > > of the code in camel-mime-filter-canon.c:filter_complete() that added > > \r\n to the stream. As far as I can tell, it should not be needed since > > filter_filter() works on a line-by-line basis and so any remaining > > buffered data *should* be an incomplete line and thus never contain a > > \n, and so I *think* my removal of that code is fine. > > Its a fallback for repairing truncated data ... its there for a reason. > It might not be the right approach for canonicalising pgp data though. > > Just #ifdef it out for now. If somethign else needs it to work like > that it can be done as a different flag, or if not, removed later. ah, okay... will do. Jeff -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
