cURL / Mailing Lists / curl-library / Single Mail

curl-library

libcurl auto creation of dirs for sftp

From: Henrik Nordberg <henrik.nordberg_at_jitterbit.com>
Date: Tue, 12 Jan 2016 19:14:20 -0800

Hi,

For sftp when CURLOPT_FTP_CREATE_MISSING_DIRS is on the code in ssh.c, in
trunk, looks like:

          if(sshc->secondCreateDirs) {
            state(conn, SSH_SFTP_CLOSE);
            sshc->actualcode = err>= LIBSSH2_FX_OK?
              sftp_libssh2_error_to_CURLE(err):CURLE_SSH;
            failf(data, "Creating the dir/file failed: %s",
                  sftp_libssh2_strerror(err));
            break;
          }
          else if(((err == LIBSSH2_FX_NO_SUCH_FILE) ||
                   (err == LIBSSH2_FX_FAILURE) ||
                   (err == LIBSSH2_FX_NO_SUCH_PATH)) &&
                  (data->set.ftp_create_missing_dirs &&
                   (strlen(sftp_scp->path) > 1))) {
            /* try to create the path remotely */
            sshc->secondCreateDirs = 1;
            state(conn, SSH_SFTP_CREATE_DIRS_INIT);
            break;
          }

In http://sourceforge.net/p/curl/bugs/1086/ it was suggested that
LIBSSH2_FX_PERMISSION_DENIED would be added because freeFTPd returns that
when you try to create a remote file and the directory doesn't exist. It
looks like servers based on weonlydo.com's .Net component, which also
includes RoboFTPd returns this. If libcurl tries to create the directory
when it gets a LIBSSH2_FX_FAILURE, I don't think it is wrong to also do it
when LIBSSH2_FX_PERMISSION_DENIED is returned (unless there is a standard
for it and it says otherwise). I have tested this with RoboFTPd and it
works. It would be great to have this added to the code base so we don't
have to create a patch to apply to every release.

I would almost go so far as to check if the directory exists upon every
failure of put.

Thanks,
Henrik Nordberg

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2016-01-13