Last Comment Bug 227267 - Upload file doesn't work well. It just upload file with zero size. [ftp only?]
: Upload file doesn't work well. It just upload file with zero size. [ftp only?]
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Networking: FTP (show other bugs)
: Trunk
: x86 Windows 2000
: -- major (vote)
: mozilla1.6final
Assigned To: Darin Fisher
: benc
Mentors:
: 215164 228286 230192 230243 (view as bug list)
Depends on:
Blocks: 4xRoaming
  Show dependency treegraph
 
Reported: 2003-12-02 03:25 PST by Pete Zha
Modified: 2004-03-09 23:09 PST (History)
25 users (show)
asa: blocking1.6+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase for ftp upload (1.58 KB, text/html)
2003-12-02 03:27 PST, Pete Zha
no flags Details
v1 patch (7.78 KB, patch)
2003-12-17 10:01 PST, Darin Fisher
doug.turner: review+
dveditz: superreview+
chofmann: approval1.6+
Details | Diff | Splinter Review

Description Pete Zha 2003-12-02 03:25:47 PST
I can't use necko to upload file on trunk. Files upload on server are zero size.
This worked fine on 1.4 branch but trunk has problem. I will upload a testcase soon.
Comment 1 Pete Zha 2003-12-02 03:27:31 PST
Created attachment 136654 [details]
testcase for ftp upload

Please modify server information to test
Comment 2 Pete Zha 2003-12-02 03:28:49 PST
Comment on attachment 136654 [details]
testcase for ftp upload

And please download this file to local and open it.
Comment 3 Pete Zha 2003-12-05 01:02:12 PST
Actually this also breaks the Webpage publish feature. The transfer process will
not stop when I upload file to ftp server using web publish.
Darin,
Do you have idea on this problem? Seems network changed a lot between 1.4 and 1.6.  
Comment 4 Ben Bucksch (:BenB) 2003-12-07 18:03:15 PST
Is this only ftp upload or also http upload? If the former, this wouldn't
prevent the review and check in of the roaming code.
Comment 5 Pete Zha 2003-12-07 20:16:03 PST
http also have problem, file size will be zero on server.

yes, It's only block the function of roaming. I will make patch and go on the
review process of roaming. But I think this should be fix before we check in
roaming feature. Otherwise it will make confuse.
Comment 6 Matthias Versen [:Matti] 2003-12-08 00:05:31 PST
Http Upload works in my win2k trunk build. Tested uploading a gif to bug 224303
Comment 7 Ben Bucksch (:BenB) 2003-12-08 00:09:32 PST
Matti, this is interesting, but does Editor's Publish function work for you,
too? This is much closer to the roaming code.
Comment 8 Pete Zha 2003-12-08 00:49:46 PST
Matti,
Maybe it's different between upload file on webpage and upload file using http
channel. Did you try the testcase?
Comment 9 Matthias Versen [:Matti] 2003-12-16 03:21:32 PST
Uploading via publishing doesn't work for me...
Comment 10 Kathleen Brade 2003-12-16 06:36:46 PST
This seems like a very bad regression.  Is it too late to block 1.6?  Do we know
approximately when this regression first appeared?  Can we pin it on a
particular checkin?
Comment 11 Kathleen Brade 2003-12-16 06:37:14 PST
*** Bug 228286 has been marked as a duplicate of this bug. ***
Comment 12 WD 2003-12-16 06:52:34 PST
It works with 1.5, but not 1.6a
(from duped bug)
Comment 13 Frank Wein [:mcsmurf] 2003-12-16 08:54:25 PST
If this should really be a regression in netwerk, here's a bonsai link
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fnetwerk&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=10%2F01%2F2003+05%3A00%3A00&maxdate=10%2F18%2F2003+05%3A00%3A00&cvsroot=%2Fcvsroot
I tracked down this regression to somwhere between 2003-10-01-05 and
2003-10-18-05 on trunk (i know that's not very exact but nightlies are missing
for that timeframe on my pc).
Comment 14 Kathleen Brade 2003-12-16 10:03:02 PST
According to Frank Wein (comment 13) and what I see in bonsai, the regression
may be caused by the checkins for
 - bug 210125 (need to be able to AsyncWait for closure only) on October 5
 - bug 192284 (support nsIChannel::open for all protocols) on October 7
Comment 15 Boris Zbarsky [:bz] 2003-12-16 10:15:19 PST
Having a smaller regression window (or a test server that could be used by
someone else to narrow the regression window) would be nice.
Comment 16 Frank Wein [:mcsmurf] 2003-12-16 11:31:58 PST
Tracked down somewhat more: This regressed between 2003-10-05-05 and 2003-10-11-05
Comment 17 Boris Zbarsky [:bz] 2003-12-16 11:56:22 PST
Right, but per comment 14 what we need to know is whether builds from the 6th
are broken....
Comment 18 Frank Wein [:mcsmurf] 2003-12-16 12:41:25 PST
yes, builds from 2003-10-06-05 are already broken
Comment 19 Darin Fisher 2003-12-16 13:28:32 PST
this is likely due to bug 210125... investigating.
Comment 20 Darin Fisher 2003-12-16 14:53:18 PST
i'm able to reproduce this using wu-ftpd on a linux box and TestUpload as the
client.

$ ./TestUpload ftp://user:pass@host/file.ext /path/to/file.ext

the result is a zero length file on the server named file.ext, and TestUpload
never seems to complete.  i'm not sure if the fact that it never seems to
complete is related to this bug or not.

investigating...
Comment 21 Darin Fisher 2003-12-16 21:04:41 PST
this bug is FTP specific.  i'm not sure it can be fixed with a trivial patch :(
Comment 22 Kim Scarborough 2003-12-17 08:14:45 PST
Reporter says it's happening on HTTP as well. That's how he found it, I believe.
Comment 23 Darin Fisher 2003-12-17 08:49:37 PST
then the HTTP problem is unrelated to this bug.
Comment 24 Ben Bucksch (:BenB) 2003-12-17 08:57:22 PST
Filed bug 228784 about HTTP.
Comment 25 Darin Fisher 2003-12-17 10:01:45 PST
Created attachment 137582 [details] [diff] [review]
v1 patch

ok, this works with my wu-ftpd testcase.  if anyone else can test this with
other servers that would be most appreciated!
Comment 26 Darin Fisher 2003-12-17 10:05:11 PST
Comment on attachment 137582 [details] [diff] [review]
v1 patch

ok, here's the deal with this patch... instead of creating a input stream pump
in the STOR case and then tearing it down in R_stor, this patch makes it so
that we setup a async stream copier from the get go.  the result, is that we
don't have to worry about tearing down the input stream pump and so we don't
have to deal with the wanky NS_ERROR_IGNORE_NOTIFICATION fubar.

note: nsIAsyncStreamCopier implements nsIRequest just like nsIInputStreamPump,
so this patch works without much need to change anything up-stream ;-)
Comment 27 Christian :Biesinger (don't email me, ping me on IRC) 2003-12-17 10:35:17 PST
the patch also works for me with ProFTPD 1.2.8
Comment 28 Daniel Glazman (:glazou) 2003-12-17 11:41:01 PST
I applied the patch to Nvu and it fixes the bug.
Thanks for the good work, Darin!
Comment 29 WD 2003-12-17 13:53:09 PST
The patch fixes the problem for me, both proftpd-1.2.9_rc2 and the FTP server
that ftp.tripod.com uses.
Comment 30 Boris Zbarsky [:bz] 2003-12-17 14:29:55 PST
Comment on attachment 137582 [details] [diff] [review]
v1 patch

I won't be able to review this until probably Tuesday.
Comment 31 Daniel Veditz [:dveditz] 2003-12-17 18:52:11 PST
Comment on attachment 137582 [details] [diff] [review]
v1 patch

sr=dveditz
Comment 32 Doug Turner (:dougt) 2003-12-17 19:04:46 PST
Comment on attachment 137582 [details] [diff] [review]
v1 patch

yes, this should work fine.  Great work Darin.
Comment 33 chris hofmann 2003-12-17 20:49:56 PST
Comment on attachment 137582 [details] [diff] [review]
v1 patch

a=chofmann for 1.6.  thanks to all for the help in knocking this one out
quickly
Comment 34 Bradley Baetz (:bbaetz) 2003-12-18 01:43:29 PST
Comment on attachment 137582 [details] [diff] [review]
v1 patch

Have you tested with OS2?
Comment 35 Darin Fisher 2003-12-18 10:37:03 PST
bbaetz: nope, i haven't tested this patch against an OS/2 FTP server.  are you
concerned about something in particular?
Comment 36 Darin Fisher 2003-12-18 10:43:08 PST
fixed-on-trunk for 1.6 final
Comment 37 Pete Zha 2003-12-18 19:05:25 PST
This patch works fine for me on windows. Thanks darin!

-Pete
Comment 38 WD 2004-01-06 06:53:32 PST
*** Bug 230192 has been marked as a duplicate of this bug. ***
Comment 39 Matthias Versen [:Matti] 2004-01-06 14:33:12 PST
*** Bug 230243 has been marked as a duplicate of this bug. ***
Comment 40 Asa Dotzler [:asa] 2004-03-09 23:01:08 PST
*** Bug 215164 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.