Closed
Bug 238847
Opened 21 years ago
Closed 21 years ago
working path's problem of FTP connection
Categories
(Core :: Networking: FTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.7final
People
(Reporter: dantifer, Assigned: darin.moz)
References
Details
(Keywords: fixed1.7)
Attachments
(1 file)
(deleted),
patch
|
dougt
:
review+
bryner
:
superreview+
asa
:
approval1.7+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040325
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040325
1.open a ftp site ,"ftp://ftp.sample.com/"
2.naviage to a site "ftp://ftp.sample.com/diraa/"
3.upload files to current path, using nsIWebBrowserPersist or nsFTPChannel, the
target URI is "ftp://ftp.sample.com/diraa/sample.txt"
4.then uploading fails for mozilla attempts to upload sample.txt to URI
"ftp://ftp.sample.com/diraa/diraa/sample.txt"
the reason is:
nsIWebBrowserPersist or nsFTPChannel will try to reuse the remaining ftp
connection for listring ftp directoris. But that connection's current path is
not "/" yet, it is "/diraa", so this connection will upload files to
"/diraa/diraa/sample.txt"
I have mentioned that ftp connection thread remove the '/' at the begin of
filepath of the URI, so I think perhaps it try to use relative path rather than
absoulte path. Is this suitable? after all, URI is URI, we can not let URI
represents different resource according usr's current browsing path.
there is also a problem for ftp disconnect policy. when to disconnect and when
to remain the connection? if this question remains, ftp uploading may have some
problems if ftp server limite its connection number from one IP.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Expected Results:
whenever you use URI to represent a file, it is the file.
clear policy for ftp disconnection.
Assignee | ||
Comment 1•21 years ago
|
||
I can reproduce this problem. I wonder how editor's publish feature manages to
avoid this problem. Or, maybe it doesn't :(
Assignee | ||
Comment 2•21 years ago
|
||
The change to make S_stor use a relative path happened in revision 1.239 of
nsFtpConnectionThread.cpp. Check-in comment mentions bug 138254 and bug 138157.
Assignee | ||
Comment 3•21 years ago
|
||
I'm working on a patch that will make us issue a CWD command prior to STOR such
that we reset the current working directory. Another option is to force the
creation of a new control connection per upload, but that sounds overkill.
-> me
Assignee: dougt → darin
Assignee | ||
Comment 4•21 years ago
|
||
This patch seems to do the trick.
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7final
Assignee | ||
Updated•21 years ago
|
Attachment #145707 -
Flags: review?(dougt)
Comment 5•21 years ago
|
||
Comment on attachment 145707 [details] [diff] [review]
v1 patch
r=dougt. pray that nothing breaks.
Attachment #145707 -
Flags: review?(dougt) → review+
Assignee | ||
Updated•21 years ago
|
Attachment #145707 -
Flags: superreview?(bryner)
(In reply to comment #1)
> I can reproduce this problem. I wonder how editor's publish feature manages to
> avoid this problem. Or, maybe it doesn't :(
It does not have to deal with this problem. for there is no remaining connection
before publishing.
Comment 7•21 years ago
|
||
Ah! That make sense!
NVU also use the NVU Site Manager that have the FTP part that transfer file to
and from the machine. I don't believe it suffer from this problem too,
hopefully it doesn't.
Assignee | ||
Comment 8•21 years ago
|
||
> > I wonder how editor's publish feature manages to
> > avoid this problem. Or, maybe it doesn't :(
> It does not have to deal with this problem. for there is no remaining connection
> before publishing.
Consider this scenario:
1. user browses to FTP site
2. user clicks on .html file
3. user selects "edit this page"
4. user goes back to browser, clicks back, and then clicks on a subdirectory
5. user now goes back to the editor and performs a publish to the original
location of the file.
Result: The file is published into the wrong directory.
I confirmed this problem exists in 1.7 beta.
Updated•21 years ago
|
Attachment #145707 -
Flags: superreview?(bryner) → superreview+
Assignee | ||
Updated•21 years ago
|
Attachment #145707 -
Flags: approval1.7?
Comment 9•21 years ago
|
||
Comment on attachment 145707 [details] [diff] [review]
v1 patch
a=asa (on behalf of drivers) for checkin to 1.7
Attachment #145707 -
Flags: approval1.7? → approval1.7+
Assignee | ||
Comment 10•21 years ago
|
||
fixed-on-trunk and fixed1.7
You need to log in
before you can comment on or make changes to this bug.
Description
•