FTPFILE_NOCWD: Avoid redundant CWDs #4382
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Hi,
here's the final integration of my changes from #4331 for FTPFILE_NOCWD when an absolute path is specified. There shouldn't be any change in behavior, only optimizations if it is determined that CWDs are not needed:
FTPFILE_NOCWD + full path:
=> preserve ftpc->prevpath
FTPFILE_NOCWD + relative path:
=> do nothing if prevpath = ""
Starting a new connection:
=> assume prevpath == "" and avoid duplicate "CWD entrypath" not just for FTPFILE_NOCWD, but in all cases.
A few observations:
The code frequently makes the assumption that slashes are not urlencoded in ftp->path: path evaluation often happens before Curl_urldecode. This is not a huge problem, but something libcurl clients need to know, and makes API usage slightly more difficult (e.g. a client has to split his FTP paths by /, then url-encode the component names, then merge again before passing as CURLOPT_URL. FreeFileSync already does that, but this could be simplified.)
When dealing with servers that require "OPTS UTF8" for UTF8 support (e.g. Microsoft FTP Service), this could break libcurl's CWD handling if ftpc->entrypath contains non-ASCII chars. libcurl retrieves ftpc->entrypath (via PWD) before a libcurl client had a chance to set "OPTS UTF8", and once he has, future "CWD ftpc->entrypath" will likely fail. This is not a problem anymore (due to this pull request) for FreeFileSync which is using absolute FTP paths, so libcurl never issues the previous command.
There is further optimization potential when libcurl clients switch between using absolute and relative paths. E.g. first FTPFILE_SINGLECWD access might download "/home/file.txt", while the second one asks for "file2.txt", so a redundant CWD could be avoided, because both operate in "/home".
The pull request is working correctly in my FTP test scenarios, but will likely break a few libcurl tests due to less "CWD"s, which I'll see to patch as well.
Best, Zenju