I guess because I updated the FTP app on my Android phone some time ago, I introduced some kind of incompatibility with DO. Connecting to the Anroid-SwiFTP was working quite ok some time before that update or before I updated DO the last time.
I double checked with FileZilla to see if it's a general problem, but FileZilla is able to connect just fine.
Maybe you have an idea what goes on here? This is the FTP-log with the "Debug" checkbox enabled in the FTP address book entry - all other settings at default.
Opening Connection 192.168.0.107:2121
220 SwiFTP 2.15.0 ready
--> USER xxxxxxxxxxxxx
331 Send password
--> PASS ...
230 Access granted
--> SYST
215 UNIX Type: L8
--> FEAT
211-Features supported by FTP Server
UTF8
MDTM
MFMT
MLST Type*;Size*;Modify*;Perm
211 End
--> OPTS MLST type;modify;size;perm;
200 MLST OPTS Type;Size;Modify;Perm;
--> OPTS UTF8 ON
200 OPTS accepted
--> REST 100
200 OPTS accepted
--> TYPE A
550 Restart position > 0 not accepted in ASCII mode
--> ABOR
200 ASCII type set
502 Command not recognized
--> ABOR
502 Command not recognized
Connection closed
The after two OPTS commands, the server responds to the REST 100 command (used to check if the server supports resuming) by saying OPTS accepted. That response doesn't make sense, and may be causing Opus to assume the server does not support resuming (and thus it would not make sense to sent REST 0 to reset the resume position).
So you mean it's more likely that SwiFTP does something weird? If yes, I will try to contact the author of SwiFTP next.
FileZilla looks like this, no sign of some "REST 100" command it seems.
Looks like FileZilla isn't testing for resume support. Maybe it only checks it when it needs to instead of on connection.
I would ask the server authors if there's a reason they return a 200 status instead of 350 after the REST command is sent, and show them the log. The response indicating an OPTS command after something else is also worth mentioning. Maybe the sequence of commands is putting the server into a confused state for some reason.
Thanks Leo. o) I read some FTP-specs (ohdear o) and wonder why DO sends "REST 100" in the first place?
Is it required to fetch the list of items? I mean upon connecting, I did not send a or receive a file yet.
DO also seems to send the "REST 100" command even though the transfer mode has been set to binary. In ASCII mode, resuming seems to be not supported officially (encoding/positioning issues), so I wondered again, why the REST command shows up.