Closed Bug 51446 Opened 26 years ago Closed 26 years ago

only 2 directories/files are shown in a ftp directory

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: face-hugger, Assigned: mozilla)

References

(
URL
)

Details

(Keywords: helpwanted, regression, Whiteboard: [dogfood-][rtm++])

Attachments

(2 files)

Screen shot of how the ftp looks like.
71.40 KB, image/gif
Details
Work around issue with dates from locales having dots (".") in them
771 bytes, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/20000905 BuildID: 2000090504 If URL points to a ftp directory (ftp://ftp.cdrom.com/pub ) only 2 items are displayed...although this directory contains lots of directories this works with all ftp sites I tried. this bug is a showstopper for browsing ftp sites. all proxies are disabled. Reproducible: Always Steps to Reproduce: 1.enter this url: ftp://ftp.cdrom.com/pub 2. 3. Actual Results: only 2 directories are displayed: 1eidos 3dfiles Expected Results: there should be displayed at least 40 and more directories this works in older builds e.g. 2000082408
Build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/2000090504 I don't have this problem. I see all directories in the URL specified. Running Win2k SP1.
Summary: only 2 directories/files are shown in a ftp directory → only 2 directories/files are shown in a ftp directory
wfm.
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Now I'm puzzled. I installed Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20000919 on a fresh installed Win98SE and yes I see this bug. I tried the same version on Win2k-SP1 and see this bug either. Is something missing in the mozilla installer? I'm using the smaller installer distrib file. (mozilla-win32-installer.exe )
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
From 53980: I'm seeing that on every FTP page I'm visiting (win32 2000-01-05-04 trunk): Only 2 entries (diectories/files) per directory are shown. Taht means, e.g. at ftp://ftp.mozilla.org/pub/nightly/ I get the first 2 entries, if I click the twisty on one of those 2 directories, the first 2 entries of that subdirectory are shown (and so on, if you have another dir in there). If that also happens in branch builds, NS6 FTP support would be unuseable for a big number of people... BTW, is this also happening on other platforms than win32?
Keywords: rtm
argh, forgot to confirm - also look into #53980 for some comments - more and more people seem to see this. Is that happening only on win32 platform(s) or also on others?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dogfood, helpwanted
*** Bug 53980 has been marked as a duplicate of this bug. ***
Suggest: Platform=ALL, OS=All, StatusWhiteboard="[dogfood-][rtm-]", serverity=critical, Priority=P2. This are the settings of bug 53980 which had been marked as duplicate of this one.
Tobias, I agree with most of those suggestions except status whiteboard. The people who can decide this should reconsider this as it is happening more and more to people as it seems and is making ftp almost unuseable. Severity and priority seem ok, and if anyone on Linux ot Mac can confirm, the platform&os settings are ok, too. A confirmation from Linux and/or Mac user(s) would be good though.
> A confirmation from Linux and/or Mac user(s) would be good though. If you insist: Shows the adverted bug with local proftpd (as user), ftp20.netscape.com (anonym.), ftp.fu-berlin.de (anonym.) using 2000-10-04-21/Linux.
oh, sorry, didn't know you're on Linux :/ I'm not owner of the bug but I hope it's ok if I set the suggested attributes as the duped bug also had them set...
Severity: normal → critical
OS: Windows 95 → All
Priority: P3 → P2
Hardware: PC → All
->rjc bucket and minus for both dogfood and rtm.
Assignee: gagan → rjc
Whiteboard: [dogfood-][rtm-]
Target Milestone: --- → Future
I just tried ftp'ing to ftp://ftp.cdrom.com/pub on both Win and Linux... both show a ton of files (72, to be example), not just two... so marking WORKSFORME. Please verify with a recent build.
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → WORKSFORME
Using 2000-10-09-18/Linux (Mozilla nightly) I still see only two directories. -> Reopening
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → WORKSFORME
Again, still WORKSFORME... let's let QA try and reproduce this.
Can it be that it fails with the current trunk (and mozilla nightly) and works with with the branch or/and commercial daily builds? Robert, I'd like to know which version you tested.
still doesn't work for me on 2000-10-09-08 on German Windows 98. As I see, all WORKSFORME were english/US people, all peoplw which see the bug seem to be from Germany/Austria, regarding their e-mail. Is that right?
> Robert, I'd like to know which version you tested. WORKSFORME with both branch as well as trunk builds.
Please DO NOT CLOSE THE BUG since you do not see the problem!!! See the attaced file. A screenshot of the ftp. Also look at the build ID (Mtrunk) + see the window name + see the modified field is blank (and never showed smth on all systems). Can it be related? I'm using win98se (PE?) with russians local settings. Also I saw it on Win2000 with russian settings and win98SE RUS, and winMe Russian settings. The problem cannot be moved to Future coz for me (and who is seeing this bug) it is not possible to use FTP with Mozilla! Let's try to get some help from I18N?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> Please DO NOT CLOSE THE BUG since you do not see the problem!!! I'm marking this bug WORKSFORME (since it does) so that QA will get a chance to do some testing.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → WORKSFORME
OK. Should I reopen this bug (since it does not WORKSFORME) or what? If QA also do not see it? If you do not see it does not solve the problem other's are seeing!!!!!!! When the bug is open it exists, but when it is closed then...
works for me mozilla 2000100920/win2000
Reopening (it is silly to WFM this bug every time just because it works on some computers!) It *does not work* with 10/10 build on Win98SE German version (Mozilla Trunk not branch), adding regression keyword as it used to work. It really seems to be an issue with international (especially German) OS versions. There was already an issue with not showing the date in FTP in bug 30994. If you don't see the bug, please try to reproduce it (on WinNT) via "Go to ControlPanel and open Regional Settings then Select "German (Standard)"." It might work. Superfluous to mention that it makes FTP totally unusable?!
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: WORKSFORME → ---
I see this too on Win98 Build 2000100208. I'll try with the newest build later.
I see this also with Linux (Mozilla nightly 2000-10-09-18). LANG=de_DE.ISO-8859-1. If I unset LANG I see more than three (ups) files and see the last modified date! This is really a I18N bug! (see bug 30994 these bugs may even be duplicates!)
Sebastian Späth, all regional settings can be changed only with reinstall the win.
I'm seeing the same problem. User agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001010 BuildID: 2000101020 Operating system: WinNT 4 SP6a, german Regional settings: German (Germany)
It works fine on Win98 build 2000101008 *WITH ENGLISH REGIONAL SETTINGS*.
I have been able to reproduce this problem in German Win 95 using 2000101108 branch build. I also tried in Spanish Win 95 and French 98 and they worked fine. I'm copying Daniel in Ireland to try and reproduce it in Win 98 DE, Win 2K DE and NT. I don't have these systems here. Yes, we need to fix this, it makes ftp unusable for German (for now) users.
Has anyone with US-NT tried Sebastian Späth suggestion (2000-10-11 00:57), to try to reproduce it by: "Go to ControlPanel and open Regional Settings then Select "German (Standard)"." If we can get this to reproduce on US-NT, it will make it much easier for rjc (or whoever) to debug. Also, can folks help pinpoint when the regression first started?
msanz@netscape.com, it is not only the German version. As mentioned above although happens at least with Russian versions.
You can also reproduce the bug if you set the Regional Settings in US NT to German. Same problem happens.
Using Linux to test is even easier. Try: LANG=de_DE.ISO-8857-1 or LANG=cz_CZ or FR_fr or "deutsch". It works using LANG=en_US or LANG= or en_AU or zh_CN.GB2312 (date is displayed as in en_US) or LANG=spanish. My idea that it must be the name of the month is not true: fr_FR and sp_SP are oct (en_US is Oct, de_DE is Okt), but fr_FR doesn't work and sp_SP does.
sr=ftang
Whiteboard: [dogfood-][rtm-] → [dogfood-][rtm+]
rjc and ftang fixed this before I could commit my comment! Just for testing data purposes here is more info: The problem is probably to be related to date formats with periods, '.'s. I reproduced this on USWin95 by going into Control Panels\Regional Settings, clicking on the Date tab, customizing the short date format to "mm.dd.yyyy" (before changing, it used '/' not '.' as the delimiter, then went to an ftp site (in my case: ftp://sweetlou.mcom.com inside the firewall), and the directory listing: .message 314 README 314 Changing the date format back to using '/', I see a full directory listing including dates in the third column.
r=gagan for that patch.
Would any of the callers of the routine being patched be messed up by the fact that it now nulls out its input parameter and never returns failure status anymore? We're worried about side-effects for this change.
Whiteboard: [dogfood-][rtm+] → [dogfood-][rtm need info]
PDT: There are no other calls to the function that was modified.
Whiteboard: [dogfood-][rtm need info] → [dogfood-][rtm+]
rtm++. FTP has to work on non-US machines.
Whiteboard: [dogfood-][rtm+] → [dogfood-][rtm++]
*** Bug 56100 has been marked as a duplicate of this bug. ***
Fixed.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Verified fixed in W98 DE and Win2k pro DE using build 2000-10-12-21-Mtrunk
*** Bug 56783 has been marked as a duplicate of this bug. ***
*** Bug 56783 has been marked as a duplicate of this bug. ***
verified on branch: winNT 2000101908 mac os9 2000101908 Linux rh6 2000101909
Keywords: vtrunk
*** Bug 59492 has been marked as a duplicate of this bug. ***
verfied with trunk build 200110604 (Win2k DE)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: