Amit Kumar Chugh | 1 Jun 09:52 2005

Problem while saving a file on server through FTP

Hi,

 

I m trying a multithreaded application by that more than one file can be store on server at a time…..

 

But when I try to save a file it store as (NIL) why. so? why not from it’s real name….

It was not a big problem till the application was not multithreaded…..

Bcz after pacing the file I just renamed it in it’s actually name….

 

Can any one gives my some sample in .NET by that file will store as it’s original name….not by (NIL)…bcz it just overwrite by other threa….

 

 

Pls send a reply to me on amit.it7 <at> gmail.com...

 

Thanks & Regards

Amit Kr. Chugh

 

 

 

 

 

 

Daniel Stenberg | 1 Jun 10:01 2005
Picon

Re: Problem while saving a file on server through FTP

On Wed, 1 Jun 2005, Amit Kumar Chugh wrote:

> I m trying a multithreaded application by that more than one file can be 
> store on server at a time...

...

> But when I try to save a file it store as (NIL) why. so? why not from it's 
> real name..

Then how do you upload? And what libcurl version?

The most common mistake is that you don't provide a remote file name in the 
URL you use when FTP uploading.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

christophe.legry | 1 Jun 15:41 2005

Build Curl 7.13.0 to Open vms 7.1-2

I must build modified version of 7.13.0 Curl to Open vms 7.1-2.
I used the procedures in "Curl_dir/packages/vms" but there are lot of unresolve.
(configure procedure can execute only for Unix family)

Please, what is the procedure to build Curl for Open vms, step by step ?
Thanks for your help

Best regards
Christophe

Jean-Marc Desperrier | 1 Jun 17:25 2005
Picon

Re: Ldap URL and binary entries

Daniel Stenberg wrote:

> So what letters _are_ unsafe then? Or perhaps we should reverse the 
> logic and only output it as-is if we find it only contains safe 
> letters. I take it this means safely printable? Like isgraph() and space?

I'll copy you the grammar from the RFC. It must be a  SAFE-STRING :

SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
                           ; any value <= 127 decimal except NUL, LF,
                           ; and CR

SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
                           %x21-39 / %x3B / %x3D-7F
                           ; any value <= 127 except NUL, LF, CR,
                           ; SPACE, colon (":", ASCII 58 decimal)
                           ; and less-than ("<" , ASCII 60 decimal)

SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]

As a special case, if the final character is a space, you must encode.

> BTW, your patch makes the code not compile for me anymore, since I 
> have no 'struct berval' anywhere...

In my setting, it came from this include line at the top of ldap.c
# include <winldap.h>
which defines it as
typedef struct berval {
    ULONG  bv_len;
    PCHAR  bv_val;
} LDAP_BERVAL, * PLDAP_BERVAL, BERVAL, * PBERVAL, BerValue;

OpenLDAP for Linux/OS X, etc. has it with :
#include <lber.h>
typedef struct berval {
 ber_len_t bv_len;
 char *bv_val;
 } BerValue, *BerVarray;

I don't think the size of the first element is guaranteed to be the same 
on all platforms, so it's better to get it from the correct include than 
redefining it.

> I find the mixing of the meaning odd. First, it selects type of output 
> and then it selects which entry in a multi-valued attribute?
>
> Can't we make the type of output respect CURLOPT_TRANSFERTEXT instead? 
> If we consider the ldif format to be text, and then add a 
> CURLOPT_LDAPNUMENTRY or similar?

Yes, this is a good idea except that I understand CURLOPT_TRANSFERTEXT 
defaults to binary, and here we really want to default to ldif.

> And I haven't really read up on this (yet), but is there really no way 
> to specify that number using the LDAP URL format?

Not that I know.
I've seen in the past discussions about an extension to include a filter 
on them in the URL, but that's a syntax very few LDAP servers support 
and it requires to already have some info about what there is in the values.
I've found the reference, it's in RFC 3876. It's not even obvious how to 
include that in URL.

Carducci, Gerald G | 2 Jun 06:21 2005

RE: Fwd: Bug#311112: curl: Escape <space> in HTTP requests

How do I remove myself from this newsgroup; my email account is getting flooded! Help!

-----Original Message-----
From: curl-users-bounces <at> cool.haxx.se
[mailto:curl-users-bounces <at> cool.haxx.se]On Behalf Of Daniel Stenberg
Sent: Sunday, May 29, 2005 11:22 AM
To: libcurl development; curl-users <at> cool.haxx.se
Cc: 311112 <at> bugs.debian.org
Subject: Re: Fwd: Bug#311112: curl: Escape <space> in HTTP requests

On Sat, 28 May 2005, Domenico Andreoli wrote:

(This is a reply to the libcurl list that this was sent to, but the report (or 
wish actually) regards curl the command line tool. Therefore, this is also 
sent to the curl-users list where follow-ups should be taken, if any.)

> For example mp3 files often contain space characters in their
> filename, however curl will not deal with that:

This is very much on purpose.

First, curl operates and URLs and spaces are not part of legal URLs.

curl is as liberal as possible to what URLs it accepts and lets through (as 
long as it can extract the host name etc). It allows users to send lots of 
weird things through to servers.

Having curl translate illegal letters into something else would take a lot of 
effort and "intelligence" in the tool I much rather avoid. Is translation to 
%20 *always* wanted when you pass a space in the URL? I doubt that.

Also (of course) different servers and different protocols will treat that 
literal space differently.

> Of course *I* could do the escaping and invoke curl 
> 'http://downhill.aus.cc/testingcurl/with%20space'

That is what you are expected to do. If you want a %20 sent to a HTTP server.

> however in that case I'll end up with a file named "with%20space" locally if 
> I use -O and will need to do manual de-escaping with mmv, too.

Yes, but if you don't like what -O gives you, why not use -o and intent your 
own file name?

--

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Daniel Stenberg | 2 Jun 12:59 2005
Picon

Re: Ldap URL and binary entries

On Wed, 1 Jun 2005, Jean-Marc Desperrier wrote:

> SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]

Heh, ok, now I understand your hesitation...

>> BTW, your patch makes the code not compile for me anymore, since I have no 
>> 'struct berval' anywhere...
>
> In my setting, it came from this include line at the top of ldap.c

...

> OpenLDAP for Linux/OS X, etc. has it with :
> #include <lber.h>

> I don't think the size of the first element is guaranteed to be the same on 
> all platforms, so it's better to get it from the correct include than 
> redefining it.

Yes, but... eh, this is the point where you'll start thinking my comments are 
getting really annoying:

The current source code builds fine without any LDAP headers available (on 
*nix)! I personally don't have any OpenLDAP things installed on any of the 
hosts I build (lib)curl on...

So, in order to apply your patch, we need to make sure that we can include the 
lber.h LDAP header, and then we need to make sure it exists and then we need 
to extend the configure check and we then disable the ability to run-time 
detect and use LDAP even when built on a system without LDAP.

While I have no problems with that approach, I would then rather do the full 
jump and skip the whole run-time loading of the symbols and instead make use 
of the functions the "ordinary" way and link with the libs etc. It would also 
solve the nasty issue we have with possible ldap API incompabilities.

>> Can't we make the type of output respect CURLOPT_TRANSFERTEXT instead?
>
> Yes, this is a good idea except that I understand CURLOPT_TRANSFERTEXT 
> defaults to binary, and here we really want to default to ldif.

Ah, right... I wonder if we could simply switch the default for LDAP. It feels 
really bad to add an option with basically the same meaning, only a reversed 
default value!

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

Jean-Marc Desperrier | 2 Jun 15:28 2005
Picon

Re: Ldap URL and binary entries

Daniel Stenberg wrote:

> On Wed, 1 Jun 2005, Jean-Marc Desperrier wrote:
>
>> SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
>
> Heh, ok, now I understand your hesitation...

Oh, it's not that complex, the syntax makes it look worse.
Maybe I'd even better code it than continue discussing it much longer in 
fact.

>> I don't think the size of the first element is guaranteed to be the 
>> same on all platforms, so it's better to get it from the correct 
>> include than redefining it.
>
> [...] So, in order to apply your patch, we need to make sure that we 
> can include the lber.h LDAP header, and then we need to make sure it 
> exists and then we need to extend the configure check and we then 
> disable the ability to run-time detect and use LDAP even when built on 
> a system without LDAP.

OK. After thinking some more about it, an architecture where the size of 
the first element is not equal to size_t would be seriously 
braindamaged, or trying to use a 32 bit LDAP from a 64 bit curl, with 
which the rest of the calls are not compatible anyway.

So redefining it with size_t seems a reasonable solution.

> [...]. It would also solve the nasty issue we have with possible ldap 
> API incompabilities.

Well, that's your call.

>>> Can't we make the type of output respect CURLOPT_TRANSFERTEXT instead?
>>
>> Yes, this is a good idea except that I understand 
>> CURLOPT_TRANSFERTEXT defaults to binary, and here we really want to 
>> default to ldif.
>
> Ah, right... I wonder if we could simply switch the default for LDAP. 
> It feels really bad to add an option with basically the same meaning, 
> only a reversed default value!

OK, then I can resubmit the patch with CURLOPT_LDAPNUMENTRY, inverted 
logic CURLOPT_TRANSFERTEXT, and redefining locally struct berval (maybe 
with the name struct curl_berval ?) using size_t for the first element.

Tor Arntsen | 3 Jun 09:39 2005
Picon

Autobuild-logs as attachments?

I have a question about logs sent to curl-autocompile <at> haxx.se:

It turns out that many of my logs are not getting through our firewall
(which contains a mail-proxy) because the log files break RFC 821 w.r.t.
maximum line lenght.  In particular, if test 056 fails ('HTTP POST with *HUGE*
request and chunked transfer encoding') it'll generate diffs with extremely
long lines of '+aaaaaaaaaaaaaaaaaaaaaaaa'...

That's why, for example, you don't see my IRIX 6.2 MIPS C 6.2 o32 reports 
these days.. that build always fail test 056. The mail from my autobuild 
stops in our firewall.

Possibly we could do something about the tests themselves..  but would it be
possible to e.g. make a tar file or something of the log, and send it as an
attachment? Would the autocompile handler be able to handle some form of that?
If so I could presumably add something to my autobuild setups that could
encapsulate the logs so to avoid the RFC 821 line length limit.

-Tor

Tor Arntsen | 3 Jun 09:44 2005
Picon

Re: Autobuild-logs as attachments?

p.s. I will try for now to send some of my build logs another way as to avoid
our local proxy limit.

-Tor

Daniel Stenberg | 3 Jun 10:15 2005
Picon

Re: Autobuild-logs as attachments?

On Fri, 3 Jun 2005, Tor Arntsen wrote:

> Possibly we could do something about the tests themselves..

Yes we could, but it would feel a bit crappy to have to limit or edit the test 
cases just because we can't deliver the test case logs properly!

> would it be possible to e.g. make a tar file or something of the log, and 
> send it as an attachment? Would the autocompile handler be able to handle 
> some form of that? If so I could presumably add something to my autobuild 
> setups that could encapsulate the logs so to avoid the RFC 821 line length 
> limit.

There's already the curl upload possibility, which allows you to formpost the 
logs over to the site using curl. I just recently patched the scripts behind 
this approach to work even better.

But if the "plain" mail approach doesn't work and the formpost is not 
suitable, I'll be prepared to write up something that allows a tarball, gzip 
or whatever as an attachment. Let me know what your tests show and what your 
preferred format would be, and I'll work on supporting it.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html


Gmane