New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FTP download fails with "No such file or directory" when CURLOPT_FILETIME is enabled #9357
Comments
The main problem here is of course that 550 is overused as a return code so it is the same for "missing file" as for "not permitted". We cannot "use a heuristic on the plain text". The text can be anything and we cannot depend on that. But I just checked the docs: we can safely convert this one become a non-fatal error and instead have Do you want to work on a fix for this? |
The 550 is overused as a return code for multiple error case, e.g. file not found and/or insufficient permissions to access the file. So we cannot fail hard in this case. Adjust test 511 since we now fail later. Reported-by: Michael Heimpold Fixes curl#9357
I'd try my best 😄 It is just as simple as in my proposal? I guess I missed something in the big picture... awaiting your feedback. |
I think so. It would of course also be good to do a test for the specific case where MDTM fails but the file is still present and gets downloaded but there's no |
Yes, I'll check/add... |
Tests related/affected according: test 511 - FTP with FILETIME and NOBODY but missing file test 1913 - FTP with NOBODY set, getting a missing file test 1914 - FTP with NOBODY and FILETIME set, getting a missing file I'll add a new test as you suggested: test 3027 - Get a file via FTP but 550 after MDTM command |
The 550 is overused as a return code for multiple error case, e.g. file not found and/or insufficient permissions to access the file. So we cannot fail hard in this case. Adjust test 511 since we now fail later. Add new test 3027 which check that when MDTM failed, but the file could actually be retrieved, that in this case no filetime is provided. Reported-by: Michael Heimpold Fixes curl#9357
The 550 is overused as a return code for multiple error case, e.g. file not found and/or insufficient permissions to access the file. So we cannot fail hard in this case. Adjust test 511 since we now fail later. Add new test 3027 which check that when MDTM failed, but the file could actually be retrieved, that in this case no filetime is provided. Reported-by: Michael Heimpold Fixes curl#9357 Closes curl#9387
The 550 is overused as a return code for multiple error case, e.g. file not found and/or insufficient permissions to access the file. So we cannot fail hard in this case. Adjust test 511 since we now fail later. Add new test 3027 which check that when MDTM failed, but the file could actually be retrieved, that in this case no filetime is provided. Reported-by: Michael Heimpold Fixes curl#9357 Closes curl#9387
The 550 is overused as a return code for multiple error case, e.g. file not found and/or insufficient permissions to access the file. So we cannot fail hard in this case. Adjust test 511 since we now fail later. Add new test 3027 which check that when MDTM failed, but the file could actually be retrieved, that in this case no filetime is provided. Reported-by: Michael Heimpold Fixes curl#9357 Closes curl#9387
The 550 is overused as a return code for multiple error case, e.g. file not found and/or insufficient permissions to access the file. So we cannot fail hard in this case. Adjust test 511 since we now fail later. Add new test 3027 which check that when MDTM failed, but the file could actually be retrieved, that in this case no filetime is provided. Reported-by: Michael Heimpold Fixes curl#9357 Closes curl#9387
I did this
I want to download a file from an FTP server and enabled CURLOPT_FILETIME by default in my curl context.
However, some FTP servers are configured more strictly so that the MDTM command is rejected with 550 error "Permission denied".
curl translates the 550 to "File not found", however, the file is actually present and when I don't set CURLOPT_FILETIME, then the download works fine. See the following trace:
I expected the following
I would expect that the download still works with CURLOPT_FILETIME set - personally, I consider it more as optional thing - if it works then it's fine - if not then it's still ok. In function ftp_state_mdtm_resp for example an unsupported reply is also handled in such a way, that no error is thrown.
However, I know that the FTP server responses are some kind of implementation specific: for some servers 550 is really "File not found", some servers (as above) use it for permission things.
In my eyes, there are three options to handle it:
I want to discuss here, whether you also consider it as issue and which solution should be worked on.
curl/libcurl version
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
But this is still present in latest Github branch.
operating system
I'm still on Ubuntu 18.04 on my dev host, but I also tested with newer libcurl on an embedded Linux system (Yocto based).
The text was updated successfully, but these errors were encountered: