Menu

#748 postquote commands not being sent to remote sftp s

closed
libcurl (356)
5
2013-06-21
2008-06-30
billmon
No

I've observed that on multi-interface sftp operations (and it might also occur on easy interface, nbut I did not check this), postquote commands (as in curl_easy_setop(CURLOPT_POSTQUOTE, <some cmd slist>) are not being sent to the sftp server [after the transfer] as they should be.

In a debug session, I observed that the ssh.c::ssh_done function was prematurely exiting when the state flag 'done' is still 0 and when there are queued-up post quote commands still not processed (I believe conn->proto.sshc.state == SSH_SFTP_QUOTE at the return).

I'm attaching a patch that I tested and it appears to work however, given that it introduces a "while" loop over the call to ssh_multi_statemach, I would greatly appreciate it if a more seasoned libcurl developer would double-check the change.

Discussion

  • billmon

    billmon - 2008-06-30

    Patch to make it work. Please double check!

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-06-30

    Logged In: YES
    user_id=1110
    Originator: NO

    Yes I can see how this patch cures the problems you experience, but this fix will also effectively make the multi interface block (and busy-loop internally) during the entire time it sends the post quote commands.

    I would instead suggest that the bug here is that we don't have a proper system internally that allows the multi interface to remain in the CURM_STATE_DONE state until the protocol is completed with its business. If you check lib/multi.c:1352 it is a call to Curl_done() that then unconditionally continue to the next state (CURLM_STATE_COMPLETED) without any means to do differently.

    A sensible fix would probably be to insert a new state after DONE but before COMPLETED, and have protocols able to switch to that state when they have multiple things to do when done. Noticably, the FTP code has the same post-quote problem already and it does the "blocking" part but without busy-loop.

    I could agree to a incomplete fix to this problem to add while we're planning or working on the "real fix", if it would remove the busy-looping.

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-07-09

    Logged In: YES
    user_id=1110
    Originator: NO

    Assuming that you won't do anything further on this issue, I'll add a mention of this flaw in the KNOWN_BUGS document.

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-07-09
    • status: open --> pending
     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • SourceForge Robot

    • status: pending --> closed