curl-library
Re: [PATCH] SFTP file listing suggestion
Date: Thu, 9 May 2013 13:40:28 +0300
Hello,
I see the point about CURLE_QUOTE_ERROR - I had too narrow view at QUOTE
commands. I used the QUOTE as the only operation itself - create directory,
rename file, etc. In case QUOTE is the part of a bigger operation,
CURLE_QUOTE_ERROR, of course, makes more sense than the real underlying
error.
I think, that my use case - using QUOTE as a self-sufficient operation -
has its right for living too. Maybe we could come up with some decision
that will suite both use cases? What about:
- returning actual error code if QUOTE is the sufficient operation - we
know that if 'set.upload' is FALSE and 'set.opt_no_body' is TRUE
- masking QUOTE error code with underlying error (for example,
CURLE_QUOTE_ERROR | CURLE_REMOTE_FILE_NOT_FOUND) (note, that this is just a
suggestion and I understand that current error codes are not ready to be
masked)
- getting actual result using curl_easy_getinfo (however we will need the
list of results in case of multiple QUOTE commands)
Of course, there is always the ability to log the underlying error and
parse it in the client code, but as for me, such approach is too complex
for such a task, and it's too error prone - I never feel sure, when I have
to rely on some text in the output, as I'm afraid that the error message
can change.
Concerning '*' prefixed quote commands - as far as I understand, these
changes do not affect them in any way. If command is prefixed with '*', it
sets 'acceptfail' to TRUE, and neither of the changed lines is executed in
such case.
Best Regards,
Pavel
> On Wed, Apr 24, 2013 at 11:01:10PM +0200, Daniel Stenberg wrote:
> > 4 - your change for CURLE_QUOTE_ERROR to become
> sftp_libssh2_error_to_CURLE()
> > is not really related to the new callback and I would ask you to submit
> that
> > as a separate patch (which we could merge at once)
>
> I'm not entirely sure about this one. This would make it impossible to tell
> when an error was due to a quote command or when it was due to a subsequent
> file transfer. It's also worth checking if this would affect '*'
> prefixed quote commands.
>
> >>> Dan
>
>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
- application/octet-stream attachment: 0001-more-specific-error-codes-in-case-of-quote-command-f.patch