238847 - working path's problem of FTP connection

Status: RESOLVED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[ZF.Dang]

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.

Comment 1

[Darin Fisher]

I can reproduce this problem.  I wonder how editor's publish feature manages to
avoid this problem.  Or, maybe it doesn't :(

Comment 2

[Darin Fisher]

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.

Comment 3

[Darin Fisher]

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

Comment 4

[Darin Fisher]

Attachment: v1 patch

This patch seems to do the trick.

Comment 5

[Doug Turner (:dougt)]

Comment on attachment 145707 [details] [diff] [review]
v1 patch

r=dougt.  pray that nothing breaks.

Comment 6

[ZF.Dang]

(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

[Zook Valem]

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.

Comment 8

[Darin Fisher]

> > 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.

Comment 9

[Asa Dotzler [:asa]]

Comment on attachment 145707 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to 1.7

Comment 10

[Darin Fisher]

fixed-on-trunk and fixed1.7