Freebox V5 HD

Salut,

Oui, j’ai exactement le même problème depuis quelques temps. Tout dépent du client FTP utilisé. Exemple sous Linux: ncFTP a le bug, le client FTP standard n’a pas le bug. Il ne se produit qu’à l’affichage, en faisant ‘dir’. Par exemple un ‘cd’ sur le répertoire, en rajoutant la lettre manquante, fonctionne correctement.

De plus pour les softs FTP qui ont le problème, la lettre ne manque QUE si la date du fichier ou du répertoire est ancienne. J’ai l’impression que c’est lié à l’année du fichier/répertoire différente de l’année actuelle, ce qui expliquerait qu’avec avec le changement récent d’année, c’est beaucoup plus visible, si beaucoup des fichiers/répertoires sont de 2009.

Stellar7

Merci.

Pour être plus précis, j’ai trouvé exactement où était le problème: certains clients FTP “parsent” le résultat de la commande ls/dir sur un FTP et récupèrent les données inhérentes aux fichiers pour proposer des fonctions avancées comme la complétion, etc. C’est le cas de ncftp:

Sous FTP classique:
ftp> dir
200 Command Okay.
150 File Status OK.
drwx–x–x 9 freebox freebox 117 Nov 19 2009 Disque dur
drwxr-xr-x 42 freebox freebox 32768 Feb 08 21:44 NO NAME

Sous NCFTP (qui fait du “parsing”):
ncftp / > dir
drwx–x–x 9 freebox freebox 117 nov 19 23:59 isque dur
drwxr-xr-x 41 freebox freebox 32768 fév 8 21:44 NO NAME

Le problème vient du fait que le serveur FTP de la Freebox ne met pas 2 espaces après les dates sous format mois/jour/année, ce qui fait un décalage avec les lignes dont les fichiers s’affichent sous format mois/jour/heure. Dans le code source de ncftp, on remarque que le programme récupère le début du nom du fichier à partir d’un emplacement fixe (voir dans unls.c), correspondant à 13 charactères après le début de la date → d’où la troncature du nom pour les fichiers dont la date ancienne, s’exprime en mois/jour/année.

En résumé, pour corriger le bug, il faut que le serveur FTP de la freebox retourne:
ftp> dir
200 Command Okay.
150 File Status OK.
drwx–x–x 9 freebox freebox 117 Nov 19 2009 Disque dur
drwxr-xr-x 42 freebox freebox 32768 Feb 08 21:44 NO NAME

Avec 2 espaces après l’année pour les fichiers avec date mois/jour/année (comme la norme le suggère, il me semble).

Stellar7.

Grrrr, la mise en page du post a supprimé les 2 (deux) espaces entre le “2009” et “Disque dur”...
Mais ils doivent bien être présent dans le retour de la commande dir du dernier exemple

Stellar7.

Elle vient d’où cette norme qui imposerait 2 espaces entre la date et le nom de fichier ou bien un emplacement fixe pour le nom de fichier ?
En tout cas la RFC précise bien que le résultat de la commande LIST est OS-dépendant et donc qu’aucun formalisme particulier ne peut être attendu :

RFC 959 October 1985

LIST (LIST)

          This command causes a list to be sent from the server to the
          passive DTP.  If the pathname specifies a directory or other
          group of files, the server should transfer a list of files
          in the specified directory.  If the pathname specifies a
          file then the server should send current information on the
          file.  A null argument implies the user's current working or
          default directory.  The data transfer is over the data
          connection in type ASCII or type EBCDIC.  (The user must
          ensure that the TYPE is appropriately ASCII or EBCDIC).
          Since the information on a file may vary widely from system
          to system, this information may be hard to use automatically
          in a program, but may be quite useful to a human user.

Elle vient d’où cette norme qui imposerait 2 espaces entre la date et le nom de fichier ou bien un emplacement fixe pour le nom de fichier ?

Imposer ne veut pas dire suggérer... Merci de bien lire ce que j’écris. J’avais en effet vu dans une RFC un exemple de réponse à commande “ls” sous FTP qui montrait 2 espaces après la date, sour format Mois/Jour/Année. Mais je n’arrive pas à remettre la main dessus parmi les multiples RFCs impactant directement ou indirectement le FTP...

Plusieurs clients FTP, et non des moindres (voir historique de ce bug-repport) présentent ce problème. Donc à moins que leurs auteurs aient tous eu la même “mauvaise idée” en même temps de considérer la longueur des données fixe, il doit bien y avoir une ambiguite concernant le format de réponse du serveur FTP à une commande “ls”.

D’ailleurs ma réponse est imprécise: les deux espaces peuvent être avant ou après l’année. Par exemple sur ftp.free.fr ou ftp.gnu.org: c’est avant.

Elle vient d’où cette norme qui imposerait 2 espaces entre la date et le nom de fichier ou bien un emplacement fixe pour le nom de fichier ?

C’est surtout que le FTP est une merde en général et plus particulièrement LIST.

En dehors des RFC, qui sont parfois à coté de leurs pompes, il y a des usages, dont il faut juger de la pertinence au cas par cas. Quand la RFC dit quelque chose d’aussi utile que “This command causes a list to be sent” il est normal que les implémentations créent des normes de fait (au pluriel, ce qui est merdique). (La solution aurait évidemment été d’envoyer des données taguées (comme XML, sémantiquement - je ne parle pas de la syntaxe affreuse). Trop tard. :( )

En attendant d’éradiquer le FTP, mieux vaut coller aux normes de fait.