GR8FTP bug report thread

Hmmm, I think it was too late for me yesterday to notice the result of the size command versus the size mentioned after the retr command.
By the way, I use the ftpd package on Ubuntu 16.0.4.3 LTS (x86_64).

Here is the captured stream:

220 odie FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
user msx
331 Password required for msx.
pass ***********
230 User msx logged in.
cwd ftp
250 CWD command successful.
size myfile.txt
213 40
mdtm myfile.txt
213 20171108224550
type i
200 Type set to I.
pasv
227 Entering Passive Mode (192,168,178,29,220,28)
retr myfile.txt
150 Opening BINARY mode data connection for 'myfile.txt' (38 bytes).
226 Transfer complete.

There is a mismatch. Actual file size is 38 bytes, size command returns 40 bytes and FTP-DATA transfers 38 bytes.
If you look at RFC3659 paragraph 4, you can see that the returned value of SIZE depends on TYPE.
I think you should issue SIZE after TYPE.

Just started a telnet session and repeated the commands.
After 'type i' size returns 38.
After 'type a' size returns 40.

Now get <filename> works!

And then there is the next issue

getr is not working for me. Maybe it is a Linux thing?
This is the last part of the capture:

pwd
257 "/home/msx/ftp" is current directory.
stat .
211- status of .:
total 8
-rw-rw-r-- 1 maase maase   38 nov  8 23:45 myfile.txt
-rw-rw-r-- 1 maase maase 2641 nov  9 22:27 otherfile.txt
211 End of Status

I assume the Windows 7 FTP server has a slightly different output...

When looking at RFC959 it seems that stat with a given path behaves like the list command. The next part from the RFC is relevant:

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.

You might want to use NLST since that seems to be intended for machines:

The server will return a stream of names of files and no other information.  The data
will be transferred in ASCII or EBCDIC type over the data connection as valid pathname
strings separated by <CRLF> or <NL>

However, now the listing comes over the data connection which might complicate your implementation a bit.

RFC3659 mentions MLST and MLSD commands but they are not implemented by ftpd that is in use by Ubuntu.

But at least I can transfer a file over the network to my MSX now. For now I only need to have one single file, so I am happy!

Mmm... The result is the same as the Windows one when configured in Linux mode (filename is the 9th space-separated field ). I first started GR8FTP using the LIST command, but the sync. between the 2 connections was not reliable (most of the time the first connection received the "2xx End of list (or something)" immediately because the server is super-fast compared to MSX, and waiting for an end of transmition on the other connection sometimes caused partial transfers, and you also have to wait for a time-out in order to be sure everything has been sent... that was quite unreliable and also slow, at least on our 8 bit machine!).

So I'd prefer to continue using the STAT command... and it look it should work according to your output here! Please give more details on what's happening (the full "getr" command you entered, and also the MSX output, be sure to use the "verbose 1" command).

I've indeed put the binary mode command right after connection (in order to avoid re-issuing it for each file), but that was not a good idea. I think I'll use a "binaryModeSet" boolean to keep track of it (and still send it only once).

211- status of .:
total 8
-rw-rw-r-- 1 maase maase   38 nov  8 23:45 myfile.txt
-rw-rw-r-- 1 maase maase 2641 nov  9 22:27 otherfile.txt
211 End of Status

So, Windows uses the same format when instructed to use Unix style, but has a different return code :

220 Microsoft FTP Service
stat .
213-status of .:
    drwxrwxrwx   1 owner    group               0 Nov  9 16:47 APPS
    -rwxrwxrwx   1 owner    group             335 Nov  7  0:35 AUTOEXEC.BAT
    drwxrwxrwx   1 owner    group               0 Sep 10  2016 AUTORUN
    -rwxrwxrwx   1 owner    group              33 Sep 10  2016 AUTORUN.INF
    drwxrwxrwx   1 owner    group               0 Nov  7  0:35 BIN
    -rwxrwxrwx   1 owner    group           23935 Sep 10  2016 COMMAND2.COM
    -rwxrwxrwx   1 owner    group            8556 Nov 11  2010 COMMAND2.TXT
    -rwxrwxrwx   1 owner    group            2565 Nov  7  0:35 MSXDOS2.SYS
    drwxrwxrwx   1 owner    group               0 Nov  9 16:49 MUSICS
    -rwxrwxrwx   1 owner    group            4467 Sep 10  2016 NEXTOR.SYS
    -rwxrwxrwx   1 owner    group              55 Nov  7  0:35 REBOOT.BAT
    drwxrwxrwx   1 owner    group               0 Sep 10  2016 SAVES
    drwxrwxrwx   1 owner    group               0 Nov 10  0:32 SOFARUN
    drwxrwxrwx   1 owner    group               0 Nov  9 16:45 TESTS
213 End of status.

213 instead of 211 for the same "End of status" !

Official doc is:

211 	System status, or system help reply.
212 	Directory status.
213 	File status.

Should be 212 (we are listing a directory here), but both system are returning different status... Ah well...

I think I'll just check for generic "2xx" which is the "Positive Completion reply" return code.

I tried gr8ftp (version 2.2) in cooperation with my fritz box. I can connect, however I cannot login I tried connecting from the command line using:

gr8ftp 192.168.0.250

Then I get a:
220 Fritz!Box FTP server ready

This works. Then I try to login using the user command (I tried user=test, user*test and user test) in all three cases I get a:

500 'USER': command not understood

When I do this from a linux machine using the ftp command, I can login normally so the test user is OK.