Hi Daniel,

i'm not sure we are fully understanding each other

On Tue, 25 Sep 2007, Daniel Stenberg wrote:

> It really does not make sense to set this option unless you
> also at the same time *force* libcurl to only do absolute, full path CWD
> commands
> In my view, that would be nicer to offer as a new
> CURLOPT_FTP_FILEMETHOD method

Do you mean unless using CURLFTPMETHOD_NOCWD ? Because then I believe
you're not making enough sense either :)

This new option would actually be compatible
with all existing CURLOPT_FTP_FILEMETHOD settings and should definitely not
exclude them. Making it a new CURLOPT_FTP_FILEMETHOD would mean we
lose all other CURLOPT_FTP_FILEMETHOD possibilities for this call.

Illustration:

If the user's homedir is /one/two/, CWDing into an absolute path like
/one/three/ works just fine for all CURLOPT_FTP_FILEMETHOD settings
without having to return to the user's home dir. (so with or without
CURLOPT_FTP_ABSONLY)

NOCWD : LIST /one/three/
SINGLE: CWD /one/three
MULTI : CWD / - CWD one - CWD three

A subsequent call to /four/five/ will work perfectly with or without
CURLOPT_FTP_ABSONLY. If not CURLOPT_FTP_ABSONLY, libcurl will first
return to the entry path stored at the initial transfer.

So to me, it should extend the selected CURLOPT_FTP_FILEMETHOD, rather
then replacing it.

> The reason is that if you'd set this new CURLOPT_FTP_ABSONLY option on a
> default libcurl easy handle, you'll effectively break subsequent
transfers in
> a non-obvious way.

Obviously, the default value of CURLOPT_FTP_ABSONLY is false, so without
specifying it to true, libcurl works just like it does now.

Yes, when setting it to true, libcurl expects the user to
specify an absolute path. And this should be documented.

If the user specifies CURLOPT_FTP_ABSONLY, but does not supply
an absolute path, then things will probably go wrong upon the
next transfer. In other words, the user should 'know what he is doing'.

In my opinion, this is not very different from many other options:

Setting CURLOPT_WRITEDATA to something other than a *FILE without
CURLOPT_WRITEFUNCTION will probably cause failure.
If you pass CURLOPT_ERRORBUFFER without allocating the buffer ...

Now, we could forget the absolute/relative path aspect. And make
a new option CURLOPT_FTP_NOENTRYPATH or something. Because that
is actually what i am trying to get at: not returning to the
entry path when re-using.
Again, the user is supposed to know what the option implies, so it
should be correctly documented.

After all, when treating an absolute path, returning to the user's
home directory is superfluous in the first place.

Or am i missing something in your logic ?

kind regards
Immanuel
Received on 2007-09-26