Closed Bug 61235 Opened 19 years ago Closed 17 years ago

FTP year display off by one sometimes

Categories

(Core :: Networking: FTP, defect, P2)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: tenthumbs, Assigned: dougt)

References

Details

(Keywords: helpwanted, testcase)

Here's what my wu-ftpd 2.6.0 server says for a LIST command:

total 7
drwxrwxr-x   2 root     wheel        1024 Apr  7  1998 bin
drwxrwxr-x   2 root     wheel        1024 Aug 30  1993 etc
drwxrwxr-x   2 root     wheel        1024 Nov 27 13:58 incoming
drwxrwxr-x   2 root     wheel        1024 Nov 17  1993 lib
lrwxrwxrwx   1 root     root            8 Nov 27 13:58 new -> incoming
drwxrwxr-x   2 root     wheel        1024 Nov  7 19:46 pub
drwxrwxr-x   3 root     wheel        1024 Aug 30  1993 usr
-rw-r--r--   1 root     root          312 Aug  1  1994 welcome.msg

Mozilla displays this as:

300: 127.0.0.1:1669
200: filename content-length last-modified file-type
201: bin 0 04/07/98 12:00:00 AM DIRECTORY
201: etc 0 08/30/93 12:00:00 AM DIRECTORY
201: incoming 0 11/27/99 01:58:00 PM DIRECTORY
201: lib 0 11/17/93 12:00:00 AM DIRECTORY
201: new 0 11/27/99 01:58:00 PM SYMBOLIC-LINK
201: pub 0 11/07/00 07:46:00 PM DIRECTORY
201: usr 0 08/30/93 12:00:00 AM DIRECTORY
201: welcome.msg 312 08/01/94 12:00:00 AM FILE

Note that the year is off by one for both "incoming" and "new." Note
also that it only happens for the current date, 2000-11-27 here because
"pub" has the same time format but mozilla gets the right year.

BTW, 4.76 has the exact same problem so mozilla may have inherited an
ancient bug.
I see what's happening.

The server is speaking UTC, which seems eminently reasonable, but
mozilla is speaking local time. In
mozilla/netwerk/streamconv/converters/nsFTPDirListingConv.cpp,
nsFTPDirListingConv::ConvertUNIXDate compares the server date with
the current local time. Since I'm on Eastern time, mozilla thinks a
recent date in the future.

Note that users in Europe and Aisa will never see this bug while
users in Hawaii will see it fro about half a day.

I can find no way to determine if a server is talking UTC or not, so
maybe mozilla should test against both local time and UTC. Of
course, it would have to switch the test order depending on whether
the current offset is positive or negative.

Maybe it should just test days, not hours and minutes. Maybe it
shouldn't bother at all.
ftp bugs to component:ftp
Assignee: gagan → dougt
Component: Networking → Networking: FTP
Target Milestone: --- → M19
Blocks: 62354
Target Milestone: --- → Future
Keywords: helpwanted
qa to me.
QA Contact: tever → benc
*** Bug 93828 has been marked as a duplicate of this bug. ***
reassigning to bbaetz@cs.mcgill.ca.
Assignee: dougt → bbaetz
Hmm. I may have fixed this in bug 78148. Lets wait for that to land, and then
recheck.
Depends on: 78148
Keywords: helpwanted
Target Milestone: Future → mozilla0.9.7
+verifyme, testcase - I will check.
Keywords: testcase, verifyme
Not fixed in a 10-05-21 nightly.

This bug is about providing correct data not about displaying data.

Simple demonstration, if you run Linux:
1) create a new file in the anonymous ftp directory.
2) make sure your ftp server returns times in UTC, wu-ftpd does it by 
default, ProFTPD has an option.
3) set your local system time to zone time zone in the western 
hemishpere.
3) point mozilla at your ftp server and note that the file you just 
created appears to be a year old.
See bug 106114. We now don't do timezone conversion, so this should be fixed.
The fact that we can't know sucks, I'll admit, but I cna't do much about it. See
that bug for discussion.

There is code to deal with this, and a quick glance doesn't show anything wrong.
If its not fixed, I'll look into it.
If an 11-22-08 nightly is supposedly fixed, then no this isn't fixed.  
Bug 106114 seems to be about proper displaying but that won't help with 
bad data, which is what this bug is about.

Let's try this again. The ls -l Unix listing format does *not* include a
year if the date is less than 6 months ago.  Mozilla attempts to be
clever by temporarily assuming the current year. If the assumed date is
older than now moziila accepts it. If the date is in the future mozilla
assumes that the year is wrong and subtracts 1. The problem is that time 
zones make it possible for a time to appear to be a few hours into the 
future. Mozilla gets this case wrong.

The current code is a crock. Mozilla should just convert times into 
integers (I know there are PR_* finctions to do that) and compare them 
rather than all this comparing monts and days, etc. If the proposed time 
is < now then accept it. If the proposed time > now + a fudge factor 
then subtract 1 from the year.
The problem is that if we're not given a year (which we aren't) AND we don't
know the remote timezone (which we don't), then the answer will be ambiguous. In
your example, what if the file had been created (1 year-1 hour) ago, and the
remote server's timezone is the same as ours? How do we separate that case from
your case? We have to get one of them wrong[1]

Converting a time into seconds-since-the-epoch and comparing, vs comparing and
then converting to a time_t makes no difference - we have to consider a fudge
factor somewhere.

[1] OK, techincally on Feb 29th, then we can know which year it must have been
modified in. I'm not going to add code for that, as it doesn't help the other
99.9% of the time.
The problem seems to be that Mozilla doesn't have enough of a fudge factor, or
doesn't have one at all.  The one-hour fudge factor used by "ls" isn't enough
when dealing with multiple time zones and systems whose clock might be off; I
would recommend using a 1-month fudge factor forward.
Well, currently we don't have nay fudge factor.

One month seems a bit too much, though - I don't think we need to deal with ftp
servers which are that broken. 1-2 days seesm reasonable, though.
You need at least 26 hours. The server could be displaying UTC+13 local
time and you could be in UTC-13. Yes, the time zones exist. Two days is
probably reasonable although I wouldn't object to a longer interval.
Missed 0.9.7, ->0.9.9
Target Milestone: mozilla0.9.7 → mozilla0.9.9
I tried this a couple of months ago, but there were quite a few edge cases.

-> 1.0
Priority: P3 → P2
Target Milestone: mozilla0.9.9 → mozilla1.0
only nsbeta1+ bugs can have milestones, resetting to ---
Target Milestone: mozilla1.0 → ---
back to 1.0
Target Milestone: --- → mozilla1.0
no time, -> 1.0.1
Keywords: verifymehelpwanted
Target Milestone: mozilla1.0 → mozilla1.0.1
Is there anything wrong with just displaying the literal time presented by the
server? If you don't know where in the world it is (and there is no way to
tell), I don't understand the tangible benefit of doing time conversion.
Can confirm this bug on 1.0 rc3 on sparc solaris.  OS is not restricted to Linux.
 Mozilla 1.0 still has this bug. 

 A convention used by many ftp servers is to return date and time (with no year)
if the date is within plus or minus six months from current, but to return the
year instead of the time in the field if the file is older than that. The reason
is that a single field is allowed for either year or time but not both, so it
can display the file time or the file year but not both.

 Mozilla seems to interpret these files as a year "backwards" from the current
date instead of within a +/- 6 month sliding window. 
 This is partcularly disconcerting when dealing with recent files uploaded to an
FTP server which is "ahead" of you in the time zones, or even across the
International Date Line. 

 Mozilla should be fixed to use a sliding +/- 6 month "year" window when
displaying the date of file listings that return a time instead of a year. 

 Quick testcase: Manually set the date to one day ahead on an FTP server. Access
the ftp server and list the file. It will show as being one year older than it
is. Wait one day (or set the file date back to today) and it will display
correctly. Alternatively, set the local system date/time to past/future to
duplicate the symptom. 

I have no time to work on mozilla at the moment, so dougt is taking over FTP

open ftp bugs -> him
Assignee: bbaetz → dougt
when we move to a new list parser, this bug should go away.
Depends on: 95590
Target Milestone: mozilla1.0.1 → Future
Fixed by 95590
Marking this fixed per comments above (fix for bug 95590)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
tenthumbs, can you give us an update? You should be able to compare mozilla 1.1
and 1.2a, if I remember this correctly.
Mozilla now displays what the server sent so, yes, I  think this bug is fixed.
VERIFIED/fixed, per contributor.

If you have a public URL, please add it to the field.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.