i'm currently building an application which should support ftp over a
number of different kinds of systems we have at our company. Some of them
do not have a 'standard' file system (standard like /dir/dir/dir/...)
The different system types include Tandem and Alpha.
Alpha has these paths: disk[dir.dir....]file
Tandem has 2 file systems, called FTP API's, one is Guardian:
$disk.directory.file, one is OSS: /dir/dir/dir/...
Now, the Tandem ftp server allows switching from one file system to
another by sending QUOTE commands, which libcurl supports perfectly. But
what libcurl also does, is CWD to it's entrypath at the initialisation of
each subsequent transfer. Why libcurl does that is completely justified,
and i am not contesting it.
However, this FTP Tandem server does not allow CWDing into Guardian
directories when in OSS API and vice versa.
Let me illustrate:
most users end up in the Guardian API after logging in, their entry path
is something like $disk.directory. libcurl stores this path. Then i allow
the users to switch to the OSS API by sending a QUOTE command to the
server upon the next transfer. But, as the connection gets re-used,
libcurl first issues a CWD $disk.directory before CWDing into the newly
requested path (something like /dir/dir/dir). Sadly, as we were in the OSS
API, the ftp server replies with a 550 and libcurl bails out.
I tried using CURLFTPMETHOD_NOCWD, and this works fine for retrieving
files, however it does not work for listing directories.
When specifying CURLFTPMETHOD_NOCWD, libcurl puts the entire path into
conn->data->reqdata.proto.ftp->file and later on decides it should do RETR
instead of LIST (because conn->data->reqdata.proto.ftp->file is not NULL).
Then there is CURLFTPMETHOD_SINGLECWD. Well this works fine on the first
transfer, but at the second transfer, libcurl tries to go back to the
So what would be more interesting? "fixing" the (non-compliant)
CURLFTPMETHOD_NOCWD, or consider an additional curl_easy_setopt() option?
An option in which i promise to use only absolute paths and which will
prevent libcurl from CWDing into the entry path (in case of re-use of the
connection). In addition, this option would actually be friends with each
one of the CURLOPT_FTP_FILEMETHOD options.
What do you think ?
Received on 2007-09-18