Errors on Files with names beginning with numbers

[cyrus]

Hello,

I'm using a recent 3.2.1 filezilla and the listing of some files (name and size) is false.
This bug is more than just visual, files wrongly displayed can not be downloaded.
Comparing with an older version (2.2) it seems to me that the problems concerns files having their names beginning with a number, or begining with a number and having a blankspace, etc...

See screenshots, where original filename

02Conversion PDF Output-StartPage_000000001.pdf weight 541078b modification date 11/02 at 2 o clock is displayed:

PDF Output-StartPage_000000001.pdf, weighting 11 o, mod date 02/02
So seems to be a lag: files seem to have their size displayed as their modification date, their modification date as their modification time and so on

Odd enough, some dates are not concerned: 07 and 10 for example...

See attached files
Thanks in advance for any help

Distant OS is AIX 5.3

[cyrus]

screen shots

[Tim Kosse]

Please enable "Show raw directory listing" in the settings dialog, refresh the directory and attach a copy of the raw listing from the message log to this ticket.

[Tim Kosse]

Your server uses the following directory listing format:

perms links user group size day month time

The problem is the exotic, localized date format.

A proper server would use use English month names and the following order:

perms links user group size month day time

It is not possible to reliably parse exotic directory listings. For each conceivable listing format, there exist servers using it. And also other servers using a different, yet indistinguishable format.

Simple example, suppose you get this date: 04/05/06. There are six ways to interpret it and I've seen all in use.

The solution for your problem:

• Stop server
• Set locale to English
• Start server again

[cyrus]

hum

I don't think that this is that simple.
It IS possible to reliably parse exotic directory listings, because FileZilla 2.2 does.
Using the 3.2 version, directory listing works in some cases. "Exotic characters" are present in both cases.
So I guess that this case merits a second thought.

Replying to codesquid:

Your server uses the following directory listing format:

perms links user group size day month time

The problem is the exotic, localized date format.

A proper server would use use English month names and the following order:

perms links user group size month day time

It is not possible to reliably parse exotic directory listings. For each conceivable listing format, there exist servers using it. And also other servers using a different, yet indistinguishable format.

Simple example, suppose you get this date: 04/05/06. There are six ways to interpret it and I've seen all in use.

The solution for your problem:

• Stop server
• Set locale to English
• Start server again

[Tim Kosse]

At the same time FZ 2.x fails to correctly parse other exotic formats.

Simple example, look at the word "gift". In English it means present. In German it means poison. Now what happens if somebody understands both English and German? Lacking context, he has to decide on the meaning.

Same happens with directory listings, they too lack context. FZ3 just prefers another, indistinguishable exotic listing format over your own listing format.

[cyrus]

I understand that a generic response saves time and brain ressources.
What I'm trying to explain is that FZ 3 works in some cases.
Comparing two cases where the first works and the second fails, the only exotic character is a "é", and it is present in both cases. So it is not the cause.
The only difference is a number:
"11 fév" -> Fails
"10 fév" -> Works
"07 fév" works fine also

So in that case, parsing fails because of the "11" and not because of the "é".
Alright so?

FZ 2 works in any cases. Maybe not in Chinese, all right.

[Tim Kosse]

The exotic character is just part of the exotic syntax and harmless. It's the field order that is causing most of your problems.

Please perform an in-depth review of src/engine/directorylistingparser.cpp and tests/dirparsertest.cpp, that should give you the needed insight to assess the situation properly.

[cyrus]

OK, thanks for your answers.
Unfortunately I haven't the rights to change the server settings. So I guess I'll have to downgrade to FileZilla 2.2.