<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library">
    <title>gmane.comp.web.curl.library</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35663"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35662"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35661"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35660"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35659"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35658"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35657"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35656"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35655"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35654"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35653"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35652"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35651"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35650"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35649"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35648"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35647"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35646"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35645"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.web.curl.library/35644"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35663">
    <title>RE: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35663</link>
    <description>&lt;pre&gt;Hi all,

On Tue, 22 May 2012, Gokhan Sengun wrote:

[snip]

No problem - it was good to see that this solved the issue. I've had a look at the ftp code as well, and whilst I appreciate I don't know the ftp code too well, it seems a little worrying for ftp_dophase_done() to not be called if result is an error code representing a problem with the transfer, etc... especially as part of that function is supposed to close the second socket if an error occurred :-/

As such I would like to propose this fix for smtp:

static CURLcode smtp_doing(struct connectdata *conn, bool *dophase_done)
{
  CURLcode result = smtp_multi_statemach(conn, dophase_done);

  if(result)
    DEBUGF(infof(conn-&amp;gt;data, "DO phase failed\n"));
  else
    DEBUGF(infof(conn-&amp;gt;data, "DO phase is complete\n"));

  if(*dophase_done)
    smtp_dophase_done(conn, FALSE /* not connected */);

  return result;
}

You will note it is a slight reworking of what I proposed early as it may be useful to have the debug information in there ;-)

Are you able &lt;/pre&gt;</description>
    <dc:creator>Steve Holme</dc:creator>
    <dc:date>2012-05-22T15:20:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35662">
    <title>Re: [PATCH] Fixed compile error with GNUTLS+NETTLE</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35662</link>
    <description>&lt;pre&gt;

Thanks, pushed!

&lt;/pre&gt;</description>
    <dc:creator>Daniel Stenberg</dc:creator>
    <dc:date>2012-05-22T14:40:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35661">
    <title>[PATCH] Fixed compile error with GNUTLS+NETTLE</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35661</link>
    <description>&lt;pre&gt;This patch fixes the compile error with GNUTLS+NETTLE.
I use following configure options:

./configure --enable-debug --enable-warings --enable-werror
--with-gnutls --without-ssl

In nettle/md5.h, md5_init and md5_update are defined as macros to
nettle_md5_init and nettle_md5_update respectively.  This causes
error when using MD5_params.md5_init and md5_update.  This patch
renames these members as md5_init_func and md5_update_func to
avoid name conflict. For completeness, MD5_params.md5_final was
also renamed as md5_final_func.

The changes in curl_ntlm_core.c is conversion error and fixed by
casting to proper type.

Best regards,

Tatsuhiro Tsujikawa
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html&lt;/pre&gt;</description>
    <dc:creator>Tatsuhiro Tsujikawa</dc:creator>
    <dc:date>2012-05-22T13:58:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35660">
    <title>Configure curl for build with Mozilla LDAP SDK and my version of openssl: LDAPS support became disabled</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35660</link>
    <description>&lt;pre&gt;Hi,
I need to build curl with Mozilla LDAP SDK and openssl 0.9.8r with my
additions to let them all work in the same project. I run the following
configuration commands:

MY_DIR=&amp;lt;my project directory&amp;gt;
export LDFLAGS="-L$MY_DIR/lib -lcrypto -lssl"
export LD_LIBRARY_PATH=$MY_DIR/lib
export CPPFLAGS="-I$MY_DIR/include -I$MY_DIR/include/ldap"
configure --enable-ldap --enable-ldaps --with-ldap-lib=ldap50

All specified libraries are present in the specified directory. However
curl configurator reports that LDAPS support is turned off.
....
  LDAP support:     enabled
  LDAPS support:   no      (--enable-ldaps)


When I run configuration with no parameters then it reports that LDAPS is
supported.

Please help to resolve this issue and enable LDAPS for my case.

Thanks
Oleg
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html&lt;/pre&gt;</description>
    <dc:creator>slon v sobstvennom palto</dc:creator>
    <dc:date>2012-05-22T13:32:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35659">
    <title>Re: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35659</link>
    <description>&lt;pre&gt;
I see from the code that it is already a little ambiguous as to whether
I can only confirm there is no memory leak occuring.


it looks to a better idea, I copied FTP's way without big considerations.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html&lt;/pre&gt;</description>
    <dc:creator>Gokhan Sengun</dc:creator>
    <dc:date>2012-05-22T09:42:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35658">
    <title>Re: LibCurlNet problem reusing easy handle</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35658</link>
    <description>&lt;pre&gt;

Disclaimer: I know nothing about LibCurlNet

Does the verbose output tell you anything about the connection being kept open 
or closed between the separate transfers? As long as you re-use the handle I 
can't see any reason why libcurl would disconnect and then I don't see why it 
would complain like that.

I figure the error message referes to an SSL session ID re-use and libcurl 
will use that by default. Any issues in that area will probably force you to 
have to investigate how the libcurl code actually behaves with your particular 
SSL library of choice.

&lt;/pre&gt;</description>
    <dc:creator>Daniel Stenberg</dc:creator>
    <dc:date>2012-05-22T09:29:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35657">
    <title>Re: Winbuild IPv6 support always disabled in libcurl 7.25.0</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35657</link>
    <description>&lt;pre&gt;

..


Thanks, your fix has been pushed now!

&lt;/pre&gt;</description>
    <dc:creator>Daniel Stenberg</dc:creator>
    <dc:date>2012-05-22T09:13:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35656">
    <title>RE: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35656</link>
    <description>&lt;pre&gt;Hi Gokhan,


Out of curiosity do you know what the knock on effect of this is, by not calling smtp_dophase_done() ?

I see from the code that it is already a little ambiguous as to whether smtp_dophase_done() or smtp_disconnect() frees up the domain for example.

Would it not be better to do:

  if(*dophase_done) {
    smtp_dophase_done(conn, FALSE /* not connected */);

    DEBUGF(infof(conn-&amp;gt;data, "DO phase is complete\n"));
  }
 
And have smtp_doing() return the result of smtp_multi_statemach() rather than the result of a cleanup function which always returns CURLE_OK?

Just my two pennies worth ;-)

Kind Regards

Steve


-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

&lt;/pre&gt;</description>
    <dc:creator>Steve Holme</dc:creator>
    <dc:date>2012-05-22T08:26:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35655">
    <title>Re: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35655</link>
    <description>&lt;pre&gt;Thanks guys for the quick responses, debugging showed that smtp_doing was
overriding 'status' before sending it to upper layer (multi interface).
Changing smtp_doing like below fixes the problem. I checked FTP and it is
exactly doing the same thing.

  if(*dophase_done) {
    if(result == CURLE_OK) {
      result = smtp_dophase_done(conn, FALSE /* not connected */);
      DEBUGF(infof(conn-&amp;gt;data, "DO phase failed\n"));
    }
    else
      DEBUGF(infof(conn-&amp;gt;data, "DO phase is complete\n"));
  }

My testing shows it is all better now but unfortunately at work I can not
use git to run SMTP tests to make sure everything is still working fine. I
will do it later at home.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html&lt;/pre&gt;</description>
    <dc:creator>Gokhan Sengun</dc:creator>
    <dc:date>2012-05-22T05:53:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35654">
    <title>RE: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35654</link>
    <description>&lt;pre&gt;Hi Daniel,


Thank you for your quick response.

I've just ran the easy interface to see if the same thing happens and the
function also gets called here as well :)

However, the "if(status)" towards the top of the function catches the
failures which would indicate that the status code isn't being sent through
correctly under the multi interface - is this possible?

S.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

&lt;/pre&gt;</description>
    <dc:creator>Steve Holme</dc:creator>
    <dc:date>2012-05-21T22:03:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35653">
    <title>RE: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35653</link>
    <description>&lt;pre&gt;

Yes it is and it will. See lib/url.c:Curl_done() at around line 5378. It will 
however get the status code and "premature" state passed in as argument to 
enable it to act differently if need be.

&lt;/pre&gt;</description>
    <dc:creator>Daniel Stenberg</dc:creator>
    <dc:date>2012-05-21T21:40:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35652">
    <title>RE: SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35652</link>
    <description>&lt;pre&gt;Hi Gokhan,


I would expect to see CURLE_LOGIN_DENIED.


I've just looked at the code and all looks okay, however here are some thoughts:

Looking at the log files that you sent, something is incrementing the state from STOP to POSTDATA - that shouldn't happen, as far as I know, and doesn't in the case of the easy interface example you sent through. The only code that advances the state machine to POSTDATA is in smtp_done().

Not only that but as you can see in smtp_state_rcpt_resp() the result gets set to CURLE_LOGIN_DENIED and in smtp_state_postdata_resp() to CURLE_RECV_ERROR which is also the same as you are seeing.

I reckon that if you were to do the following afterwards:

long response;
curl_easy_getinfo(curl, CURLINFO_HTTP_CODE, &amp;amp;response)

I'm pretty sure you would see 500 in "response"  and not 550 as also indicated by the log file.

Can anyone who is more familiar with the multi interface tell us if smtp_done() is intentionally called even when there is a failure? It would appear that this function&lt;/pre&gt;</description>
    <dc:creator>Steve Holme</dc:creator>
    <dc:date>2012-05-21T21:33:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35651">
    <title>Re: CURLOPT_URL always lists</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35651</link>
    <description>&lt;pre&gt;
curl will always transfer a file unless explictly told otherwise. In the
case of sftp, if the URL points to a directory it will transfer a
directory listing as a file. If you want to avoid transferring a file
and just want the side effects instead (like deleting a file), use the
CURLOPT_NOBODY option.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

&lt;/pre&gt;</description>
    <dc:creator>Dan Fandrich</dc:creator>
    <dc:date>2012-05-21T20:54:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35650">
    <title>SMTP: multi interface produce wrong error code for unknown recipient</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35650</link>
    <description>&lt;pre&gt;Hello Steve and folks,

I just noticed a small flaw in SMTP when it is used with multi interface.
If the recipient is unknown by the SMTP server, libcurl ends up with error
code CURLE_RECV_ERROR instead of a more meaningful one like
CURLE_LOGIN_DENIED (which is provided with easy interface currently). I am
not saying CURLE_LOGIN_DENIED is the best error here but it is the closest
to imply the error. I am doing my tests with the git master branch.

Can you see the problem at a glance? If not, I am going to dig this
tomorrow.

Test code (smtp-multi.c).
Test code's output (multi-out.txt)
Curl command line's output (easy-out.txt)

are all attached.

Thanks

&lt;/pre&gt;</description>
    <dc:creator>Gokhan Sengun</dc:creator>
    <dc:date>2012-05-21T20:17:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35649">
    <title>CURLOPT_URL always lists</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35649</link>
    <description>&lt;pre&gt;Hi,

I'm just wondering if I'm doing something wrong or this is just how it
works. I always set CURLOPT_URL to my base url, but then it also
always lists the files and folders in the base url.
This is how my codes looks when I delete a file:

NSString username = &amp;lt; at &amp;gt;"username";
NSString password = &amp;lt; at &amp;gt;"password";
NSString* filePath = &amp;lt; at &amp;gt;"rm /UserFolder/Test.txt";
NSString* baseUrl = &amp;lt; at &amp;gt;"sftp://myftpserver.org";

struct curl_slist* headerlist = curl_slist_append(NULL, [filePath
cStringUsingEncoding:encoding]);
curl_global_init(CURL_GLOBAL_DEFAULT);
CURL *curl = curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL, [baseUrl cStringUsingEncoding:encoding]);
curl_easy_setopt(curl, CURLOPT_USERNAME, [username
cStringUsingEncoding:encoding]);
curl_easy_setopt(curl, CURLOPT_PASSWORD, [password
cStringUsingEncoding:encoding]);
curl_easy_setopt(curl, CURLOPT_POSTQUOTE, headerList);
CURLcode result = curl_easy_perform(curl);
curl_slist_free_all (headerList);
curl_easy_cleanup(curl);

With this code I can see in the output windo&lt;/pre&gt;</description>
    <dc:creator>Anders Havn</dc:creator>
    <dc:date>2012-05-21T16:47:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35648">
    <title>Re: [PATCH] add CURLINFO_SSL_VERIFYRESULT_STR providing a human-readable error string</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35648</link>
    <description>&lt;pre&gt;
Thank you for looking at the patch, Dan.  I agree that CURLOPT_ERRORBUFFER 
might solve the problem without extending the current API.  I will prepare
a better patch.

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

&lt;/pre&gt;</description>
    <dc:creator>Kamil Dudka</dc:creator>
    <dc:date>2012-05-21T15:17:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35647">
    <title>Winbuild IPv6 support always disabled in libcurl 7.25.0</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35647</link>
    <description>&lt;pre&gt;I tried to update php_curl.dll to libcurl 7.25.0, but discovered that 
IPv6 support was enabled (no matter what options I chose). At last, I 
discovered why.

This patch was incomplete:
https://github.com/bagder/curl/commit/575f3c30ed60aafddbaeeb26745cca942fb9ee2f

I commented the patch, but do not know how well these comments are 
monitored, so I am posting the same comment over here.

The change from 'yes' to 'true' in line 152 of 
winbuild/MakefileBuild.vc must be applied to line 166 as well.

Line 166:
  !IF "$(USE_IPV6)"=="yes"

Should be
  !IF "$(USE_IPV6)"=="true"

Otherwise IPv6 support will be disabled on Windows at all times.
&lt;/pre&gt;</description>
    <dc:creator>Jan Ehrhardt</dc:creator>
    <dc:date>2012-05-21T10:00:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35646">
    <title>LibCurlNet problem reusing easy handle</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35646</link>
    <description>&lt;pre&gt;Hi,

Thanks for great library!

I'm having some trouble reusing easy handle. What I do.

1) setup connection to use ssl
2) start first transfer it returns ok
3) next transfer returns CURLE_FTP_WRITE_ERROR

Additional info. When I read debug information I find following message:

"522 SSL connection failed; session reuse required: see require_ssl_reuse option
in vsftpd.conf man page

server did not report OK, got 522"

I double checked that my vsftpd has require_ssl_reuse set to YES

I include my code below. What I'm I missing or doing wrong?


using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

using SeasideResearch.LibCurlNet;
using System.Threading;


namespace Exnui
{
    static class Global
    {
        public static void Init()
        {
            Curl.GlobalInit((int)CURLinitFlag.CURL_GLOBAL_ALL);
        }


        public static void CleanUp()
        {
            Curl.GlobalCleanup();
        }
    }


    public enum &lt;/pre&gt;</description>
    <dc:creator>Lukasz Buczkowski</dc:creator>
    <dc:date>2012-05-21T07:38:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35645">
    <title>Re: libcurl 7.25 / multi / win32</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35645</link>
    <description>&lt;pre&gt;

For how long? And you're not getting any verbose output explaining what's 
happening?


...


During name resolving, there's no socket to wait for when you use the threaded 
resolver - which libcurl on windows does by default. So that return code is 
expected as long as the name resolving isn't completed.

&lt;/pre&gt;</description>
    <dc:creator>Daniel Stenberg</dc:creator>
    <dc:date>2012-05-20T21:38:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35644">
    <title>libcurl 7.25 / multi / win32</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35644</link>
    <description>&lt;pre&gt;Hi,

I've been trying to get to grips with the multi interface (everything works
fine with easy)

I initially tried to get fopen.c example working to no avail and so wrote a
simpler test program (see below)

This code runs fine but just loops as every loop curl_multi_fdset returns
with maxfd == -1

Neither my write or debug are ever called.


Tracing into curl_mult_fdset I see this line...

bitmap = multi_getsock(easy, sockbunch, MAX_SOCKSPEREASYHANDLE);

this always returns bitmap==0


Tracing into multi_getsock....

easy-&amp;gt;state==CURLM_STATE_WAITRESOLVE

which leads to the following getting called...

int Curl_resolver_getsock(struct connectdata *conn,
                          curl_socket_t *socks,
                          int numsocks)
{
  (void)conn;
  (void)socks;
  (void)numsocks;
  return 0;
}

This is 0 is what is bitmap is set to.

What am I doing wrong? My enviroment is :

libcurl 7.25 (static library built from project file)
win32
msvc10


Thanks in advance,

Adam


//****************************&lt;/pre&gt;</description>
    <dc:creator>adam smith</dc:creator>
    <dc:date>2012-05-20T17:39:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.web.curl.library/35643">
    <title>Re: SFTP delete file with space</title>
    <link>http://permalink.gmane.org/gmane.comp.web.curl.library/35643</link>
    <description>&lt;pre&gt;Hi

On 18 May 2012 14:22, Anders Havn &amp;lt;anders.havn&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

I think you should also be able to use something like this:

NSString* fullFilePath = &amp;lt; at &amp;gt;"sftp://myftpserver.org/";
NSString* filePath = &amp;lt; at &amp;gt;"rm \"/UserFolder/Test xyz.txt\"";

&lt;/pre&gt;</description>
    <dc:creator>Michael Wood</dc:creator>
    <dc:date>2012-05-18T15:07:38</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.web.curl.library">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.web.curl.library</link>
  </textinput>
</rdf:RDF>

