Re: [Evolution] Can't trust Evolution to send big attachments...

["Ujwal S. Sathyam" <ujwal netbrowser com>]

Yup, that is exactly what I suspected. Some thread was kicking in and and messing with the data buffer (See my comments below :-).

Great,

Ujwal

On Sat, 2001-11-03 at 01:57, Luis Villa wrote:
> Apparently (and of course Jeff and Notzed know better than I) the
> auto-save function would kick in and block/re-direct the write output.
> This is why no one in the office could replicate it, and most of the
> reports were from europeans- it kicked in mostly on modems, since they
> would take much longer to upload the large attachments that triggered
> the bug. On ethernet, you'd have to have an awfully huge attachment to
> be large enough to trigger the auto-save timeout.
> Luis
>
> On Sat, 2001-11-03 at 02:25, Ujwal S. Sathyam wrote:
> > Hurray!!!! What was the issue, if I may ask? I did spend quite a few
> > hours digging into the code, so I am curious...
> > 
> > Ujwal
> > 
> > 
> > On Fri, 2001-11-02 at 17:25, Luis Villa wrote:
> > 
> >     FWIW, after literally months of gnashing of teeth and pulling of hair
> >     over this bug, we reproduced and discovered the source of the bug today.
> >     The mail developers are trying to figure out the best solution as we
> >     speak and it'll be fixed by Monday.
> >     Luis
> >     
> >     On Fri, 2001-11-02 at 19:11, Mike Barnes wrote:
> >     > On Sat, 2001-11-03 at 03:25, Ujwal S. Sathyam wrote:
> >     > > It is not an issue with inline or attached. The attachment gets chopped
> >     > > off while it being sent. The size was about 3MB. The recipient got an
> >     > > attachment that was 32KB. I think this happens only when the SMTP server
> >     > > is remote, i.e. more than few hops away. So there is some response and
> >     > > network delay introduced. When the transmission finally begins, it goes
> >     > > OK for a while, and then some evolution thread seems to kick in and
> >     > > clear out the data buffer that is being sent. So evolution sends an end
> >     > > of data signal.
> >     > 
> >     > I just did some testing and reproduced this. I also got some truncation
> >     > of a file using the local sendmail, not just a remote SMTP server.
> >     > Admittedly, the truncation was only 57 bytes, as opposed to 5003055
> >     > bytes when sent via SMTP, but it's certainly far from the ideal.
> >     > 
> >     > I've added a hefty annotation to bug 6024, and am happy to provide any
> >     > information necessary on this one.
> >     > 
> >     > http://bugzilla.ximian.com/show_bug.cgi?id=6024
> >     > 
> >     > Mike.
> >     > 
> >     > 
> >     > _______________________________________________
> >     > evolution maillist  -  evolution ximian com
> >     > http://lists.ximian.com/mailman/listinfo/evolution
> >     
> >     
> >     
> >     _______________________________________________
> >     evolution maillist  -  evolution ximian com
> > 
> > http://lists.ximian.com/mailman/listinfo/evolution
> > 
> >     
>
>
>
> _______________________________________________
> evolution maillist  -  evolution ximian com
>     
http://lists.ximian.com/mailman/listinfo/evolution
>