Closed Bug 238847 Opened 21 years ago Closed 21 years ago

working path's problem of FTP connection

Categories

(Core :: Networking: FTP, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.7final

People

(Reporter: dantifer, Assigned: darin.moz)

References

Details

(Keywords: fixed1.7)

Attachments

(1 file)

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.
I can reproduce this problem. I wonder how editor's publish feature manages to avoid this problem. Or, maybe it doesn't :(
Blocks: 24867
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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
Attached patch v1 patch (deleted) — Splinter Review
This patch seems to do the trick.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.7final
Attachment #145707 - Flags: review?(dougt)
Comment on attachment 145707 [details] [diff] [review] v1 patch r=dougt. pray that nothing breaks.
Attachment #145707 - Flags: review?(dougt) → review+
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.
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.
> > 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.
Attachment #145707 - Flags: superreview?(bryner) → superreview+
Attachment #145707 - Flags: approval1.7?
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+
fixed-on-trunk and fixed1.7
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: