211729 - FTP listing in latest builds is broken.

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030703
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030703

I noticed this a couple of days ago, but didn't get around to checking up on it.

Reproducible: Always

Steps to Reproduce:
1. Go to QA -> Latest Builds.  (Or the FTP site directly.)

Actual Results:  
A "directory" listing with a directory entry named
"pub/mozilla/nightly/latest/".  Clicking on it results in now being in the empty
directory
"ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/pub/mozilla/nightly/latest/".

Expected Results:  
Showed the FTP equivalent of "http://ftp.mozilla.org/pub/mozilla/nightly/latest/".

I can't replicate this problem with other FTP listings, so I think it's specific
to the latest builds directory on Mozilla's FTP server only.

Comment 1

[Michael Lefevre]

I see this with 2003070408 (on win2k), but not with 1.4 final, or with IE or
WS_FTP. Therefore I don't believe it's a server problem - feels more like a
change in Mozilla that's done this.

Checking back, bug 209972 seems like a probable candidate. AIUI, Mozilla is now
just retrieving directory listings rather than changing to them and then listing
them. That \latest isn't a real directory, it's a symlink, so I guess what we're
seeing is a "listing" of the symlink rather than the directory that is linked to.

Reassigning according to my guess as to where/who this bug should be...

Comment 2

[Jason Bassford]

At the time I filed it, Mozilla.org's FTP site was the only site where I saw
this problem (it's my fault for not checking with IE).  Since then, however,
I've also noticed something similar happening with rpmfind.net's RPM links. 
Rather than get a download, I get a directory listing with one entry that has
the name of the file in it.  (No matter what, if I have the choice of 2
components, it always ends up being the one I don't choose that's correct. <grin>)

Comment 3

[Doug Turner (:dougt)]

this is a blocker.

Comment 4

[Jason Bassford]

Tweaking summary to reflect actual problem (not mozilla.org server after all)
and adding regression keyword.

Comment 5

[Doug Turner (:dougt)]

Attachment: untested patch

I think this is basically what is needed.  testers welcome.

Comment 6

[Andrew Schultz]

resgressed between linux trunk 2003070205 and 2003070310, confirming bug 209972
as the culprit

Comment 7

[Doug Turner (:dougt)]

Attachment: patch v.2

This patch brings back the CWD and PWD states.	It basically basically backs
out the FTP state reduction yet keeps the some the code clean up and relative
path changes in.

This does fix the regression.

Comment 8

[Darin Fisher]

Comment on attachment 127333 [details] [diff] [review]
patch v.2

>Index: nsFtpConnectionThread.cpp

>+// CWD            
...
>+            break;
>+            
>+           case FTP_R_CWD:
>+              mState = R_cwd();

nit: indentation


>+    nsCAutoString listString("LIST" CRLF);
> 
>     return SendFTPCommand(listString);

nit: can you use NS_LITERAL_CSTRING here?


r=darin

Comment 9

[Doug Turner (:dougt)]

Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <-- 
nsFtpConnectionThread.cpp
new revision: 1.261; previous revision: 1.260
done
Checking in nsFtpConnectionThread.h;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.h,v  <-- 
nsFtpConnectionThread.h
new revision: 1.105; previous revision: 1.104
done

Comment 10

[Jason Bassford]

.

Comment 11

[Ralf Hauser]

the problem is still here with win32 2003072404, i.e. today's build.

perhaps a quick fix would be to have a correct symbolic link in that ftp directory??

Comment 12

[Jason Bassford]

> the problem is still here with win32 2003072404

I'm not seeing it.  Same build (7/24-04) and everything is still working fine
since the fix.  I'm using XP.

Comment 13

[Ralf Hauser]

I use win2k SP3 

Comment 14

[Jason Bassford]

If somebody else using W2K can confirm this (or even if you can go to a
different W2K computer and reproduce it there), feel free to reopen the bug and
change the OS to that specific platform.

Comment 15

[Michael Lefevre]

WFM with mozilla trunk 2003072404 on win2k.

Comment 16

[Ralf Hauser]

now it works for me too. But still on
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/
I guess I wasn't aware that links hard-coded into menus might be retrieved from
the cache too.