543805 - FTP list parse error when list returns twice space between date and file name

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Luca Perico]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

One space are added at the start of every file or directory.
Apparently at the wu FTP server


Reproducible: Always

Steps to Reproduce:
1. go to  ftp://ftp.software.ibm.com/ or ftp.lotus.com
2. click on a file or a directory
3.
Actual Results:  
a %20 url are opened

Comment 1

[Ria Klaassen (not reading all bugmail)]

I see more problems on the first site. Most or at least a lot of links give an error:  550 / cloud: No such file or directory.

Is this what you mean?

Comment 2

[Ria Klaassen (not reading all bugmail)]

Core > Networking: FTP will be the right place in any case.

Comment 3

[Makoto Kato [:m_kato]]

ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 208
drwxr-sr-x  13 102004493 201            4096 Apr 18 2008  4700
-rw-r--r--   1 102004493 201            6981 Dec 20 1995  TRADEMARKS.TXT
drwxr-sr-x  14 102004493 201            4096 Oct 20 2008  aix
drwxr-sr-x  17 102004493 201            4096 Mar  4 2009  annualreport
drwxr-sr-x   8 102004493 202            4096 Oct 31 2008  as400
drwxr-sr-x   2 0        201             256 Nov  2 09:00 bin
drwxr-sr-x   3 102004493 202             256 Jun  8 2009  cloud
drwxr-sr-x   4 102004493 202             256 Apr 22 2003  common
drwxr-sr-x  19 102004493 202            4096 Jan 25 23:30 demos
drwxr-sr-x   2 0        201             256 Oct 26 14:13 dev
drwxr-xr-x   8 102004493 201             256 Mar  7 2006  devices
drwxr-sr-x  10 102004493 201             256 Apr 23 2008  education
drwxr-sr-x   4 102004493 201             256 May  6 2004  eserver
drwxr-xr-x   2 102004493 201            4096 Sep 25 2007  fiximages
lrwxrwxrwx   1 102004493 1                14 Sep 25 16:01 ftp -> software/lotus
drwxr-sr-x   4 102004493 201             256 Dec  6 2002  hardware
drwxr-sr-x   2 102004493 201             256 Oct 22 1997  ims
drwxr-xr-x   2 102004493 201             256 Mar 24 2004  indexes
drwxr-sr-x   4 102004493 202             256 Feb 16 2009  industries
drwxr-sr-x   6 102004493 201            4096 Dec 17 22:02 infomgmt
drwxr-sr-x   6 102004493 202            4096 Sep 24 13:30 itsolutions
drwxr-sr-x   3 102004493 202             256 Mar 23 2006  jp
drwxr-sr-x   3 102004493 202             256 Dec 19 2007  la
drwxr-sr-x   2 0        201             256 Oct 26 14:13 lib
drwxr-sr-x  11 102004493 201            4096 Aug  7 2007  linux
drwxr-xr-x   2 102004493 1               256 Sep  8 08:06 lost+found
drwxr-sr-x   5 102004493 201             256 Nov 29 2001  networking
drwxr-sr-x   6 102004493 202             256 Dec 18 11:48 partnerworld
drwxr-sr-x   2 102004493 201             256 Jul 17 2006  pc
drwxr-sr-x  15 102004493 202            4096 Jul 17 2008  podcasts
drwxr-sr-x  23 102004493 201            4096 Nov 13 2008  printers
drwxr-sr-x   4 102004493 202            4096 Jul 26 2006  procurement
drwxr-sr-x   7 102004493 201             256 Mar  9 2004  ps
lrwxrwxrwx   1 102004493 1                14 Sep 25 16:01 pub -> software/lotus
drwxr-sr-x  19 102004493 201            4096 Jul 22 1999  publications
-rw-r--r--   1 102004493 201              47 May 29 2007  robots.txt
drwxr-sr-x  21 102004493 201            4096 Aug 20 2002  rs6000
drwxr-sr-x  38 102004493 201            4096 Apr 28 2008  s390
drwxr-sr-x   3 102004493 202             256 Dec  8 06:25 sales
drwxr-sr-x   4 102004493 202             256 Oct 11 2006  servers
drwxr-sr-x   6 102004493 201             256 Sep 24 14:08 services
drwxr-sr-x  13 102004493 201            4096 Apr 10 2008  sns
drwxr-sr-x 268 102004493 201           16384 Feb  1 09:20 software
drwxr-sr-x   9 102004493 201            4096 Apr  8 2009  solutions
drwxr-sr-x  83 102004493 202            4096 Jan  4 13:36 storage
drwxr-sr-x  25 102004493 202            4096 Mar 12 2009  systems
drwxr-sr-x   3 102004493 202             256 Feb  5 2009  virtualworlds
226 Transfer complete.
ftp> cd aix
250-Please read the file README_AIX
250-  it was last modified on Fri Jul 26 08:09:01 1996 - 4935 days ago
250 CWD command successful.
ftp> system
215 UNIX Type: L8

LIST data has twice space beteen date and name...

Comment 4

[Makoto Kato [:m_kato]]

confirm on latest trunk of Mac OS X.

Comment 5

[Luca Perico]

@Ria Klaassen (triage)      
The problem seem the same(In reply to comment #1)
> I see more problems on the first site. Most or at least a lot of links give an
> error:  550 / cloud: No such file or directory.
> 
> Is this what you mean?
Yes the server seem the same.
Apparently the parsing code have some problem it will add a space at the begin of the file or directory name. "/ cloud" instead "/cloud" i.e.

Comment 6

[Luca Perico]

(In reply to comment #3)

> drwxr-sr-x   8 102004493 202            4096 Oct 31 2008 | as400
> drwxr-sr-x   2 0        201             256 Nov  2 09:00 |bin
                                                           ^-----
Seem the directory separated in a fixed size column or use one space after the column



> ftp> ls
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for /bin/ls.
> total 208
> drwxr-sr-x  13 102004493 201            4096 Apr 18 2008  4700
> -rw-r--r--   1 102004493 201            6981 Dec 20 1995  TRADEMARKS.TXT
> drwxr-sr-x  14 102004493 201            4096 Oct 20 2008  aix
> drwxr-sr-x  17 102004493 201            4096 Mar  4 2009  annualreport
> drwxr-sr-x   8 102004493 202            4096 Oct 31 2008  as400
> drwxr-sr-x   2 0        201             256 Nov  2 09:00 bin
> drwxr-sr-x   3 102004493 202             256 Jun  8 2009  cloud
> drwxr-sr-x   4 102004493 202             256 Apr 22 2003  common
> drwxr-sr-x  19 102004493 202            4096 Jan 25 23:30 demos
> drwxr-sr-x   2 0        201             256 Oct 26 14:13 dev
> drwxr-xr-x   8 102004493 201             256 Mar  7 2006  devices
> drwxr-sr-x  10 102004493 201             256 Apr 23 2008  education
> drwxr-sr-x   4 102004493 201             256 May  6 2004  eserver
> drwxr-xr-x   2 102004493 201            4096 Sep 25 2007  fiximages
> lrwxrwxrwx   1 102004493 1                14 Sep 25 16:01 ftp -> software/lotus
> drwxr-sr-x   4 102004493 201             256 Dec  6 2002  hardware
> drwxr-sr-x   2 102004493 201             256 Oct 22 1997  ims
> drwxr-xr-x   2 102004493 201             256 Mar 24 2004  indexes
> drwxr-sr-x   4 102004493 202             256 Feb 16 2009  industries
> drwxr-sr-x   6 102004493 201            4096 Dec 17 22:02 infomgmt
> drwxr-sr-x   6 102004493 202            4096 Sep 24 13:30 itsolutions
> drwxr-sr-x   3 102004493 202             256 Mar 23 2006  jp
> drwxr-sr-x   3 102004493 202             256 Dec 19 2007  la
> drwxr-sr-x   2 0        201             256 Oct 26 14:13 lib
> drwxr-sr-x  11 102004493 201            4096 Aug  7 2007  linux
> drwxr-xr-x   2 102004493 1               256 Sep  8 08:06 lost+found
> drwxr-sr-x   5 102004493 201             256 Nov 29 2001  networking
> drwxr-sr-x   6 102004493 202             256 Dec 18 11:48 partnerworld
> drwxr-sr-x   2 102004493 201             256 Jul 17 2006  pc
> drwxr-sr-x  15 102004493 202            4096 Jul 17 2008  podcasts
> drwxr-sr-x  23 102004493 201            4096 Nov 13 2008  printers
> drwxr-sr-x   4 102004493 202            4096 Jul 26 2006  procurement
> drwxr-sr-x   7 102004493 201             256 Mar  9 2004  ps
> lrwxrwxrwx   1 102004493 1                14 Sep 25 16:01 pub -> software/lotus
> drwxr-sr-x  19 102004493 201            4096 Jul 22 1999  publications
> -rw-r--r--   1 102004493 201              47 May 29 2007  robots.txt
> drwxr-sr-x  21 102004493 201            4096 Aug 20 2002  rs6000
> drwxr-sr-x  38 102004493 201            4096 Apr 28 2008  s390
> drwxr-sr-x   3 102004493 202             256 Dec  8 06:25 sales
> drwxr-sr-x   4 102004493 202             256 Oct 11 2006  servers
> drwxr-sr-x   6 102004493 201             256 Sep 24 14:08 services
> drwxr-sr-x  13 102004493 201            4096 Apr 10 2008  sns
> drwxr-sr-x 268 102004493 201           16384 Feb  1 09:20 software
> drwxr-sr-x   9 102004493 201            4096 Apr  8 2009  solutions
> drwxr-sr-x  83 102004493 202            4096 Jan  4 13:36 storage
> drwxr-sr-x  25 102004493 202            4096 Mar 12 2009  systems
> drwxr-sr-x   3 102004493 202             256 Feb  5 2009  virtualworlds
> 226 Transfer complete.
> ftp> cd aix
> 250-Please read the file README_AIX
> 250-  it was last modified on Fri Jul 26 08:09:01 1996 - 4935 days ago
> 250 CWD command successful.
> ftp> system
> 215 UNIX Type: L8
> 
> LIST data has twice space beteen date and name...

Comment 7

[Daniel Veditz [:dveditz]]

This does not affect 1.9.1 -- when did it regress?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

It would be good to know what is causing this - a server side configuation, maybe? Doesn't happen on ftp://ftp.mozilla.org for example ...

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Looks like a consequence of us fixing bug 484684. Their listing is incorrect (includes the space), and we used to strip them, but we now don't.

That leaves a few options, I think:
1) Back out that bug and WONTFIX it
2) WONTFIX this bug (broken server listing)
3) Try to come up with some sort of heuristic?

1) or 2) are probably the best options, though which would be best depends on the number of sites affected by each. Would also be worth investigating how other FTP clients deal with this, I guess.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Oh, looks like there's already a special case for "old Hellsoft" servers. Perhaps that needs to be extended?

Comment 11

[Michal Novotny [:michal]]

Apparently it isn't true that there is always 1 space between filename and previous token (http://hg.mozilla.org/mozilla-central/annotate/46484930f4f3/netwerk/streamconv/converters/ParseFTPList.cpp#l1202). In this case I don't see a way how to find a correct start of the filename while parsing the listing. I've looked at few anonymous wu-2.6.2 FTP servers that I've found and no other server gave me such wrong output.

We could theoretically fix it not in FTP parser but in FTP protocol so, that if RETR or LIST command fails we remove leading space (if present) from last component of the path and try again. But although this would fix this problem, it would have other side effects.

Since I haven't found other affected FTP server I would prefer to WONTFIX this bug (and possibly give a notice to IBM that their FTP servers return incompatible listing).

Comment 14

[bzilla99]

Interestingly, this path will kill IE 6 every time:
ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/

I thought it was a unique way of handling the issue.

Comment 15

[Patrik Hysky]

@bzilla99, do you really want to compare Firefox 3.6 to 9-year old IE6?

Both IE7 and IE8 handle the wu ftp server output correctly unlike Firefox 3.6 which has the %20 bug. Firefox 3.5 worked fine.

Many instances of the problem can be seen here:
ftp://www.redbooks.ibm.com/redbooks/

Comment 16

[Michal Novotny [:michal]]

(In reply to comment #15)
> Both IE7 and IE8 handle the wu ftp server output correctly unlike Firefox 3.6
> which has the %20 bug. Firefox 3.5 worked fine.

OK, but I'll bet that IE7 and IE8 can't handle filenames with leading spaces correctly...

> Many instances of the problem can be seen here:
> ftp://www.redbooks.ibm.com/redbooks/

It seems that only output of IBM's wu FTP servers is broken. Do you know any other site that is affected?

Comment 17

[bzilla99]

I avoid IE like the plague. I use Firefox on windows and mac exclusively. I was just curious how an old version of IE handled it. It was ironic (?) to see it crashed and burned.

Yes, the bug appeared in 3.6 - I often use the browser to drill down into a site and get an ftp path so I can use wget to retrieve the file from a terminal window. It isn't too hard to take the extra space out once the path is pasted elsewhere, but it's a bit annoying.

I think wu-ftp is fairly pervasive, so I'd like to see this fixed.

Comment 19

[Robin Sapiro]

Any idea if this is going to be fixed - and if so - when?

Comment 20

[Robin Sapiro]

Any idea if this is going to be fixed - and if so - when?

Comment 21

[Michal Novotny [:michal]]

(In reply to comment #17)
> I think wu-ftp is fairly pervasive, so I'd like to see this fixed.

So far, we've seen this problem only on IBM's servers. This isn't generic wu-ftp problem. Fixing this bug means reverting the patch from bug #484684. I think we don't want to do that unless somebody shows that the problem is widely spread.

Comment 22

[andreas+mozilla]

(In reply to comment #21)
> So far, we've seen this problem only on IBM's servers. This isn't generic
> wu-ftp problem.

Agreed.

> Fixing this bug means reverting the patch from bug #484684.

I respectfully disagree!

You said yourself that it's not a generic wu-ftpd bug. Reverting the change would break ALL servers, including plain wu-ftpd.

Either IBM fixes their servers (which would be my personal preference) or an IBM-specific (not all servers, or even all wu-ftpd servers!) workaround could be added. But please make sure such a workaround (if added) is applied ONLY to IBM servers to avoid breaking others.

Comment 23

[Roger Deschner]

This problem affects any FTP server running the AIX operating system, whether at IBM or anywhere else. So it is a generic problem that cannot be resolved by simply having IBM modify its own servers, or by making a special exception for ibm.com ftp servers. The issue is the output from the Unix ls command, which varies in different flavors of Unix.

I have built a test case at [ftp://ftp.uic.edu/test] which contains the following files (this output is from ls on a linemode ftp client)

-rw-r--r--   1 0                49 May  4 20:19  nodup.file
-rw-r--r--   1 0                15 May  4 20:09  test.blankfile
-rw-r--r--   1 0                15 Apr  1 2008   test2.blankfile
-rw-r--r--   1 0                15 May  4 20:09 nodup.file
-rw-r--r--   1 0                15 May  4 20:09 test.file
-rw-r--r--   1 0                15 Apr  1 2008  test2.file

Note that this differs from the output of ls on linux. In AIX the blank space is after the year, whereas on linux it is before the year.

I deliberately created the first three files with blank spaces as the first character of the file name. Then I used touch to alter the dates on some of them, so that the year would appear in place of the time. I also deliberately created a pair of two files "nodup.file" and " nodup.file" just to see what happens.

Firefox 3.6: All of the files created in 2010 could be displayed correctly, and none of the files created in 2008 could be displayed, regardless of whether the file names had leading blanks or not. This is broken behavior.

Firefox prior to the patch from bug 484684, also IE8: None of the files with leading blanks in their name could be displayed. There were two separate entries for "nodup.file", but clicking on the entry for " nodup.file" displayed the contents of "nodup.file" instead. This is also broken behavior which the patch from Bug #484684 attempted to fix, except that it created other problems.

Correct parsing of the output from ls would be: Assume that the date in ls command output is always exactly 12 characters long, even if the 12th character is a blank. The 13th character after the start of the date will always be a blank. The 14th character after the start of the date is the beginning of the file name - and it could possibly be a blank space character which is part of the file/directory name. This parsing method, of always assuming that the date stamp is exactly 12 characters long, followed by exactly 1 blank space, followed by the file name, would be compatible with all FTP servers, and would also accommodate filenames with leading blank space characters.

I will leave my AIX testcase up for you to try against possible fixes.

Comment 24

[Robin Sapiro]

(In reply to comment #23)

> Firefox 3.6: All of the files created in 2010 could be displayed correctly, and
> none of the files created in 2008 could be displayed, regardless of whether the
> file names had leading blanks or not. This is broken behavior.
> 
Roger, I like your theory - but if you have a look at the following site:

ftp://ftp.software.ibm.com/ps/products/imageplus/fixes/IWPMv2.3fp2/

You will see that while all the 2010 files handle as expected and most of the others do not that there are also a couple of 2009 files that are handled correctly in Firefox 3.6 -  specifically the 2 with a date of December 15 2009 - although it sounds to me like your suggested resolution will work for any file date

Comment 25

[Roger Deschner]

The man page for the Unix ls command states: "If the time of last modification is greater than six months ago, the time field is shown in the format month date year where as files modified within six months the time field is shown as month date time format." 

This bug does not occur with files younger than 6 months, because the time is shown instead of the year, and FTP clients (including Firefox 3.6) already know how to calculate the year correctly by following the 6-month rule. It's May 7, 2010 as I type, so a file last touched after November 7, 2009 will not exhibit this bug, whereas a file last touched before November 7, 2009 will exhibit it.

If the date is parsed as always being exactly 12 characters, possibly including a trailing blank after the year, it will always be parsed correctly when connecting to any FTP server, even if there are filenames that start with a blank space character.

BTW I reported the bug about IE8 not handling filenames that start with a blank space character to Microsoft, and they seem perplexed by it too. I haven't tried any other browsers to see how they behave on my test directory.

Comment 26

[Robin Sapiro]

(In reply to comment #25)
> The man page for the Unix ls command states: "If the time of last modification
> is greater than six months ago, the time field is shown in the format month
> date year where as files modified within six months the time field is shown as
> month date time format." 
> 
> This bug does not occur with files younger than 6 months, because the time is
> shown instead of the year, and FTP clients (including Firefox 3.6) already know
> how to calculate the year correctly by following the 6-month rule. It's May 7,
> 2010 as I type, so a file last touched after November 7, 2009 will not exhibit
> this bug, whereas a file last touched before November 7, 2009 will exhibit it.
> 
> If the date is parsed as always being exactly 12 characters, possibly including
> a trailing blank after the year, it will always be parsed correctly when
> connecting to any FTP server, even if there are filenames that start with a
> blank space character.
> 
> BTW I reported the bug about IE8 not handling filenames that start with a blank
> space character to Microsoft, and they seem perplexed by it too. I haven't
> tried any other browsers to see how they behave on my test directory.

So now that Roger has so clearly identified the problem and also how to resolve so that FF 3.6 should in my opinion work correctly with any FTP server with files of any date - what are the chances of getting this fixed?

Comment 27

[Johnny Stenback (:jst)]

Not blocking per comment 21.

Comment 28

[Roger Deschner]

As more and more users update their Firefox browsers to v3.6, we are getting an increasing number of complaints from users of our AIX-based ftp server that they cannot use it. It is complicated to explain the intricacies of this age-based bug to them. Although we generally recommend that people at the University use Firefox for everything, about all we can tell them is to switch from Firefox to IE or Safari, which is much easier than trying to get them to regress back to an earlier version of Firefox.

We have tested Firefox 4 beta and found that this bug still exists at that level. It's been a while since I explained here the exact nature of the problem with all AIX-based ftp servers, and suggested a fix that will not interfere with any other types of ftp servers or with files/directories that begin with a blank space character. This is becoming a widespread problem for us. When can we expect this to be fixed?

Comment 29

[Boris Zbarsky [:bzbarsky]]

Renominating per comment 23, since this affects more servers than was thought at the time of comment 21, and since we do not in fact have to back the fix out.

That said, Roger, this is a very low priority compared to the other things on Michal's plate.  Your best bet for getting this fixed is probably to post a patch....

Comment 30

[Johnny Stenback (:jst)]

Blocking. Michal, can you look at this in the next couple of weeks?

Comment 31

[Johnny Stenback (:jst)]

We don't need this for beta5, but moving to betaN.

Comment 32

[Michal Novotny [:michal]]

Attachment: fix

Comment 33

[Robin Sapiro]

Seems like problem is resolved in 3.6.11 - thanks to all involved

Comment 34

[Doug Turner (:dougt)]

Comment on attachment 483359 [details] [diff] [review]
fix

sorry for the delay michal, and sorry for punting to jason.

ooc, has ParseFTPList ever been updated outside of mozilla?  maybe there are other fixes that we should grab.

Comment 35

[Johnny Stenback (:jst)]

Comment on attachment 483359 [details] [diff] [review]
fix

Honza says he can help offload Jason a bit by doing this review.

Comment 36

[Honza Bambas (:mayhemer)]

Attachment: update the test to work also before May 4

This is just an update to the test.  Files that has May 4 as the date are parsed as May 4th 2010, which is logical.  I changed the date to Jan 1 that should let the parse always return the current year.

Please apply over your patch.

Comment 37

[Honza Bambas (:mayhemer)]

Comment on attachment 483359 [details] [diff] [review]
fix

r=honzab with the test fixed.

Comment 38

[Michal Novotny [:michal]]

Attachment: patch v2 - fixed dates

Comment 39

[Johnny Stenback (:jst)]

Landed.

http://hg.mozilla.org/mozilla-central/rev/b623418ab1de

Comment 40

[Daniel Veditz [:dveditz]]

Does this patch apply to the 1.9.2 branch as well, or will we need a new one?

Comment 41

[Uli Link (:ul-mcamafia)]

(In reply to comment #33)
> Seems like problem is resolved in 3.6.11 - thanks to all involved

(In reply to comment #40)
> Does this patch apply to the 1.9.2 branch as well, or will we need a new one?

Could NOT reproduce with recent 1.9.2 branch builds:
3.6.14rc1 MacOSX 10.6, 3.6.14rc AIX 5.1, 3.6.13 on W2K3 Server 
and a Minefield 4.0b10 MacOSX 10.6 and SeaMonkey 2.0.12 on Win Vista are all showing all files in the dir
"ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/python/"
correctly. 
This dir contains old and files newer the 6 months.

A "ls -l" from my AIX buildhost shows a little different listing format:

ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 131576
-rw-rw-r--    1 102004493 201         1652349 Apr 16  2001 python-1.5.2-8.aix4.3
.ppc.rpm
-rw-rw-r--    1 102004493 201         4102464 Jun 28  2001 python-2.1-1.aix4.3.p
pc.rpm
-rw-rw-r--    1 102004493 201         4118414 Oct 10  2001 python-2.1.1-1.aix4.3
.ppc.rpm
-rw-rw-r--    1 102004493 201         3687396 Feb 17  2002 python-2.2-3.aix4.3.p
pc.rpm
-rw-rw-r--    1 102004493 201         3692060 Feb 18  2003 python-2.2-4.aix4.3.p
pc.rpm
-rw-rw-r--    1 102004493 201         3697237 Feb 23  2005 python-2.2-5.aix5.1.p
pc.rpm
-rw-rw-r--    1 102004493 201         4460884 Sep 12  2005 python-2.3.4-2.aix5.1
.ppc.rpm
-rw-rw-r--    1 102004493 201         4471844 Jul 24  2008 python-2.3.4-4.aix5.3
.ppc.rpm
-rw-rw-r--    1 102004493 201         7684595 Dec 22 06:02 python-2.6.2-1.aix5.3
.ppc.rpm
-rw-rw-r--    1 102004493 201          853061 Apr 16  2001 python-devel-1.5.2-8.
aix4.3.ppc.rpm
-rw-rw-r--    1 102004493 201          515244 Jun 28  2001 python-devel-2.1-1.ai
x4.3.ppc.rpm
...

So the padding blank is before the year, I'm using en_US 8859-1 locale on my AIX buildhost.

Seems 1.9.2 is fixed or unaffected.

Comment 42

[Ben]

FTP site can be browsed ok with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 ID:20110121161358