Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4267 closed Bug report (rejected)

Errors on Files with names beginning with numbers

Reported by: cyrus Owned by:
Priority: normal Component: FileZilla Client
Keywords: directorylistingparser lag Cc:
Component version: Operating system type: Windows
Operating system version:

Description

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


Attachments (3)

filezilla-3.2.1.bug.rar (245.3 KB ) - added by cyrus 11 years ago.
screen shots
05-filezilla.JPG (37.5 KB ) - added by cyrus 11 years ago.
log.txt (12.1 KB ) - added by cyrus 11 years ago.

Download all attachments as: .zip

Change History (11)

by cyrus, 11 years ago

Attachment: filezilla-3.2.1.bug.rar added

screen shots

comment:1 by Tim Kosse, 11 years ago

Status: newmoreinfo

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.

by cyrus, 11 years ago

Attachment: 05-filezilla.JPG added

by cyrus, 11 years ago

Attachment: log.txt added

comment:2 by cyrus, 11 years ago

Operating system type: OtherWindows
Operating system version: AIX5.3
Status: moreinfonew

comment:3 by Tim Kosse, 11 years ago

Resolution: rejected
Status: newclosed

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

in reply to:  3 comment:4 by cyrus, 11 years ago

Resolution: rejected
Status: closedreopened

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

comment:5 by Tim Kosse, 11 years ago

Resolution: rejected
Status: reopenedclosed

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.

comment:6 by cyrus, 11 years ago

Resolution: rejected
Status: closedreopened

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.

comment:7 by Tim Kosse, 11 years ago

Resolution: rejected
Status: reopenedclosed

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.

comment:8 by cyrus, 11 years ago

Keywords: directorylistingparser added

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.

Note: See TracTickets for help on using tickets.