Incorrect filename parsing
|Reported by:||ninix||Owned by:|
|Component version:||3.25.1||Operating system type:||Windows|
|Operating system version:||6.1|
There seems to be a issue if a filename starts with a space character (or multiple spaces).
The FTP client will trim out all spaces from a filename and display the rest of its string (this can also be a issue with a space as the last character)
I've discovered this after some users reported that they can't delete there own files (They have full read/write access) and the message was that "550 The system cannot find the file specified.".
So I've start investigating the issue and with multiple FTP clients: WinSCP, FileZilla, Total Commander, etc... All with the exact problem. The file can't be renamed/deleted/open/etc.
The server is a "Microsoft FTP Service - Windows 2008 R2" which seems to accept filenames starting with one or multiple space characters :(
Command: DELE A D R E S A Document1.doc Response: 550 The system cannot find the file specified. Command: RNFR A D R E S A Document1.doc Response: 550 The system cannot find the file specified.
I know, is one of the weirdest names I've seen so far....
So, to solve this I've used old school FTP command line
ftp> o my.ftp.server Connected to my.ftp.server. 220-Microsoft FTP Service [...] 230 User logged in. ftp> cd file/path 250 CWD command successful. ftp> dir 200 PORT command successful. 125 Data connection already open; Transfer starting. 02-27-17 07:54AM 544768 A D R E S A Document1.doc 02-27-17 08:45AM 753624 A D R E S A Document2.doc 226 Transfer complete. ftp: 119 bytes received in 0,00Seconds 59,50Kbytes/sec. ftp> delete "A D R E S A Document1.doc" 550 The system cannot find the file specified. ftp> mdelete * 200 Type set to I. mdelete A D R E S A Document1.doc? yes 250 DELE command successful. mdelete A D R E S A Document2.doc? no ftp> delete " A D R E S A Document2.doc" 250 DELE command successful.
So, by using a buggy FTP server witch accepts unusual filenames (starting with space characters) combined with weird people writing those names the result is no more access to those files anymore.
Please redesign the filename parsing for "LIST" command, so it will accept those anomalies.