When I look at the contents of a folder using ftp:// it displays the contents of the folder when it was first visited by the user with 5.0. So for example if I go to win32/x86/current/ today on 12/03/99 I still see the contents from 11/30/99 which was the first time I visited that site with 5.0/Seamonkey. Using another ftp utility I can see that the contents of that folder had indeed been changed as recently as 12/02/99. I might actually miss a new build :-( Don't know where this bugs belongs to so I am guessing XPApps. CC'ing hyatt,rjc,warren,waterson
This has nothing to do with the cache (deduced as there is no cache yet), it has to do with the dates not being computed properly. The files are the correct ones, you can compare by going to the latest directory such as 1999-12-02-11-M12 and comparing the bits to those in the current directory. I think is this valeski's bug, reassigning.
Summary: Too much cache for ftp:// folder content display → dates in ftp directory computed wrong
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 10551 ***
Status: VERIFIED → REOPENED
Summary: dates in ftp directory computed wrong → [dogfood]dates in ftp directory wrong
Bug 10551 originally talked about GMT offset, and really isn't that big a deal. It was also pushed off to M14. THIS bug is about the dates bearing no relation to reality, being usually either 11/30 or 9/30. This means people have to fire up Communicator to check that they're really getting the latest build, which has even more importance since the Mozilla nightly directory hasn't gotten updated with the Linux builds correctly since 12/6 (adding dogfood at michaell's request)
I have a very low risk fix for this.
Summary: [dogfood]dates in ftp directory wrong → [dogfood][BETA]dates in ftp directory wrong
Putting on PDT- radar. Needed for BETA, bug not for dogfood.
per chofmann, valeski M13
*** Bug 21858 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago → 19 years ago
Resolution: --- → FIXED
fix checked in 12/20/99 7:00 pm pac time. The dates arent' perfect yet, but closer. see/append to 10551 for more info.
Dates are closer but still incorrect. Bug 10551 should cover this. Closing. NT 2000020808
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.