The patch didn't seem to work for me. Here is
the verbose output:

< 230 User padds logged in.
* We have successfully logged in
> PWD
< 257 "/usr1/padds" is current directory.
* Entry path is '/usr1/padds'
* Connected to abc.def.ghi.jkl (123.456.789.012)
> CWD asfi
< 250 CWD command successful.
> PASV
< 227 Entering Passive Mode
(123,456,789,012,213,22)
* Connecting to abc.def.ghi.jkl (123.456.789.012)
port 54550
* Connected the data stream!
> TYPE I
< 200 Type set to I.
> STOR L85020010510074736
< 150 Opening BINARY mode data connection for
L85020010510074736.
  % Total % Received % Xferd Average Speed
      Time Curr.
                                 Dload Upload
Total Current Left Speed
 26 7839 0 0 26 2048 0 594
0:00:13 0:00:03 0:00:10 0<
226 Transfer complete.
100 7839 0 0 100 7839 0 2198
0:00:03 0:00:03 0:00:00 5791
* Connection (#0) left alive
* Re-using existing connection! (#0)
* Connected to abc.def.ghi.jkl (123.456.789.012)
> CWD /usr1/padds
< 250 CWD command successful.
> PASV
< 227 Entering Passive Mode
(123,456,789,012,213,23)
* Connecting to abc.def.ghi.jkl (123.456.789.012)
port 54551
* Connected the data stream!
> TYPE I
< 200 Type set to I.
> STOR (nil)
< 150 Opening BINARY mode data connection for
(nil).
100 1155 0 0 100 1155 0 16500
0:00:00 0:00:00 0:00:00 0<
226 Transfer complete.
100 1155 0 0 100 1155 0 6416
0:00:00 0:00:00 0:00:00 0
* Connection (#0) left alive
* Re-using existing connection! (#0)
* Connected to abc.def.ghi.jkl (123.456.789.012)
> CWD /usr1/padds
< 250 CWD command successful.
> PASV
< 227 Entering Passive Mode
(123,456,789,012,213,24)
* Connecting to abc.def.ghi.jkl (123.456.789.012)
port 54552
* Connected the data stream!
> TYPE I
< 200 Type set to I.
> STOR (nil)
< 150 Opening BINARY mode data connection for
(nil).
100 1171 0 0 100 1171 0 23420
0:00:00 0:00:00 0:00:00 0<
226 Transfer complete.
100 1171 0 0 100 1171 0 6888
0:00:00 0:00:00 0:00:00 0
* Connection (#0) left alive
* Re-using existing connection! (#0)
* Connected to abc.def.ghi.jkl (123.456.789.012)
> CWD /usr1/padds
< 250 CWD command successful.
> PASV
< 227 Entering Passive Mode
(123,456,789,012,213,25)
* Connecting to abc.def.ghi.jkl (123.456.789.012)
port 54553
* Connected the data stream!
> TYPE I
< 200 Type set to I.
> STOR (nil)
< 150 Opening BINARY mode data connection for
(nil).
100 8383 0 0 100 8383 0 204k
0:00:00 0:00:00 0:00:00 0<
226 Transfer complete.
100 8383 0 0 100 8383 0 34929
0:00:00 0:00:00 0:00:00 0
* Connection (#0) left alive
* Closing live connection (#0)

Here is the url.c code that was changed:

    if(old_conn->proxyhost)
      free(old_conn->proxyhost);
    conn = conn_temp; /* use this
connection from now on */
// free(conn->path); /* free the
previous path pointer */

    /* we need these pointers if we speak over a
proxy */
    conn->name = conn->gname;
    conn->hostname = old_conn->gname;

    conn->path = path; /* use this one */
// conn->ppath = path; /* set this too */

/* The 'ppath' may have been advanced a few steps
from the 'path' start
      point. We must also advance our new pointer
as many steps as the
      previous one was! This was the cause of the
multiple ftp file bug
       found on May 9 2001 libcurl 7.7.3 */
   conn->ppath = (old_conn->ppath -
old_conn->path)+path;

    free(old_conn->path); /* free the previous
path pointer */

    /* re-use init */

I hope this helps!

Rodney

--- Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Wed, 9 May 2001, Rodney Simmons wrote:
>
> > I have found a problem. I'm using
> libcurl.dll (built with M$VC++ 6.0) to
> > transfer multiple files to a unix machines.
> The ftp url is something
> > along these lines:
>
> >
> ftp://abc.def.ghi.jkl/asfi/L85020010509124010,
> >
> ftp://abc.def.ghi.jkl/asfi/L85020010509124011,
> > etc..
>
> > The first file transfers successfully but the
> subsequent files fail
> > because libcurl cannot change to /asfi
> directory. Here is the verbose
> > output:
>
> This is an obvious bug. It stands clear to me
> that the first 'CWD' command is
> using the correct directory, while the second
> and later commands don't use
> the correct dir (but instead wrongly prefix it
> with a slash).
>
> > Is this a bug or is there some setting tham
> I'm missing? Again, this is
> > a great utility and I appreciate any help
> that I get.
>
> Please try the attached patch and see if the
> problem is fixed. I could repeat
> your problem before this was made, and after
> this change it seemed to work.
>
> Thanks for your detailed report!
>
> --
> Daniel Stenberg -- curl project maintainer --
> http://curl.haxx.se/
>
> > Index: url.c
>
===================================================================
> RCS file: /cvsroot/curl/lib/url.c,v
> retrieving revision 1.121
> diff -u -r1.121 url.c
> --- url.c 2001/05/04 07:47:11 1.121
> +++ url.c 2001/05/10 09:28:31
> @@ -2022,14 +2022,20 @@
> if(old_conn->proxyhost)
> free(old_conn->proxyhost);
> conn = conn_temp; /* use this
> connection from now on */
> - free(conn->path); /* free the
> previous path pointer */
>
> /* we need these pointers if we speak over
> a proxy */
> conn->name = conn->gname;
> conn->hostname = old_conn->gname;
>
> conn->path = path; /* use this one
> */
> - conn->ppath = path; /* set this too
> */
> +
> + /* The 'ppath' may have been advanced a
> few steps from the 'path' start
> + point. We must also advance our new
> pointer as many steps as the
> + previous one was! This was the cause of
> the multiple ftp file bug
> + found on May 9 2001 libcurl 7.7.3 */
> + conn->ppath = (old_conn->ppath -
> old_conn->path)+path;
> +
> + free(old_conn->path); /* free the
> previous path pointer */
>
> /* re-use init */
> conn->bits.reuse = TRUE; /* yes, we're
> re-using here */
>

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-05-10