Upload file doesn't work well. It just upload file with zero size. [ftp only?]

RESOLVED FIXED in mozilla1.6final

Status

()

Core
Networking: FTP
--
major
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Pete Zha, Assigned: Darin Fisher)

Tracking

({regression})

Trunk
mozilla1.6final
x86
Windows 2000
regression
Points:
---
Bug Flags:
blocking1.6 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 136654 [details]
testcase for ftp upload

Please modify server information to test
(Reporter)

Comment 2

14 years ago
Comment on attachment 136654 [details]
testcase for ftp upload

And please download this file to local and open it.

Updated

14 years ago
Severity: normal → major
(Reporter)

Comment 3

14 years ago
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.  
(Reporter)

Updated

14 years ago
Blocks: 124029

Comment 4

14 years ago
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.
(Reporter)

Comment 5

14 years ago
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.
Http Upload works in my win2k trunk build. Tested uploading a gif to bug 224303

Comment 7

14 years ago
Matti, this is interesting, but does Editor's Publish function work for you,
too? This is much closer to the roaming code.
(Reporter)

Comment 8

14 years ago
Matti,
Maybe it's different between upload file on webpage and upload file using http
channel. Did you try the testcase?
Uploading via publishing doesn't work for me...

Comment 10

14 years ago
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?
Flags: blocking1.6?
Keywords: regression
Summary: Upload file doesn't work well. It just upload file with zero size. → Upload file doesn't work well. It just upload file with zero size. [ftp only?]

Comment 11

14 years ago
*** Bug 228286 has been marked as a duplicate of this bug. ***

Comment 12

14 years ago
It works with 1.5, but not 1.6a
(from duped bug)
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

14 years ago
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
Having a smaller regression window (or a test server that could be used by
someone else to narrow the regression window) would be nice.
(Assignee)

Updated

14 years ago
Target Milestone: --- → mozilla1.6final
Tracked down somewhat more: This regressed between 2003-10-05-05 and 2003-10-11-05
Right, but per comment 14 what we need to know is whether builds from the 6th
are broken....
yes, builds from 2003-10-06-05 are already broken

Updated

14 years ago
Flags: blocking1.6? → blocking1.6+
(Assignee)

Comment 19

14 years ago
this is likely due to bug 210125... investigating.
(Assignee)

Comment 20

14 years ago
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...
(Assignee)

Comment 21

14 years ago
this bug is FTP specific.  i'm not sure it can be fixed with a trivial patch :(
Status: NEW → ASSIGNED
Component: Networking → Networking: FTP

Comment 22

14 years ago
Reporter says it's happening on HTTP as well. That's how he found it, I believe.
(Assignee)

Comment 23

14 years ago
then the HTTP problem is unrelated to this bug.

Comment 24

14 years ago
Filed bug 228784 about HTTP.
(Assignee)

Comment 25

14 years ago
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!
(Assignee)

Comment 26

14 years ago
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 ;-)
Attachment #137582 - Flags: superreview?(bz-vacation)
Attachment #137582 - Flags: review?(dougt)
the patch also works for me with ProFTPD 1.2.8
I applied the patch to Nvu and it fixes the bug.
Thanks for the good work, Darin!

Comment 29

14 years ago
The patch fixes the problem for me, both proftpd-1.2.9_rc2 and the FTP server
that ftp.tripod.com uses.
Comment on attachment 137582 [details] [diff] [review]
v1 patch

I won't be able to review this until probably Tuesday.
Comment on attachment 137582 [details] [diff] [review]
v1 patch

sr=dveditz
Attachment #137582 - Flags: superreview?(bz-vacation) → superreview+

Comment 32

14 years ago
Comment on attachment 137582 [details] [diff] [review]
v1 patch

yes, this should work fine.  Great work Darin.
Attachment #137582 - Flags: review?(dougt) → review+
(Assignee)

Updated

14 years ago
Attachment #137582 - Flags: approval1.6?

Comment 33

14 years ago
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
Attachment #137582 - Flags: approval1.6? → approval1.6+
Comment on attachment 137582 [details] [diff] [review]
v1 patch

Have you tested with OS2?
(Assignee)

Comment 35

14 years ago
bbaetz: nope, i haven't tested this patch against an OS/2 FTP server.  are you
concerned about something in particular?
(Assignee)

Comment 36

14 years ago
fixed-on-trunk for 1.6 final
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Reporter)

Comment 37

14 years ago
This patch works fine for me on windows. Thanks darin!

-Pete

Comment 38

14 years ago
*** Bug 230192 has been marked as a duplicate of this bug. ***
*** Bug 230243 has been marked as a duplicate of this bug. ***

Comment 40

14 years ago
*** Bug 215164 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.