-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rich Cook wrote:
>
> On Jul 13, 2007, at 12:29 PM, Micah Cowan wrote:
>
>>
>>> sprintf(filecopy, "\"%.2047s\"", file);
>>
>> This fix breaks the FTP protocol, making wget instantly stop working
>> with many conforming servers, but apparently st
On 7/15/07, Rich Cook <[EMAIL PROTECTED]> wrote:
I think you may well be correct. I am now unable to reproduce the
problem where the server does not recognize a filename unless I give
it quotes. In fact, as you say, the server ONLY recognizes filenames
WITHOUT quotes and quoting breaks it. I h
On Jul 13, 2007, at 12:29 PM, Micah Cowan wrote:
sprintf(filecopy, "\"%.2047s\"", file);
This fix breaks the FTP protocol, making wget instantly stop working
with many conforming servers, but apparently start working with yours;
the RFCs are very clear that the file name argument starts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rich Cook wrote:
> On OS X, if a filename on the FTP server contains spaces, and the remote
> copy of the file is newer than the local, then wget gets thrown into a
> loop of "No such file or directory" endlessly. I have changed the
> following in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Steven M. Schweda wrote:
>>From :
>
>> [...]
>>char filecopy[2048];
>>if (file[0] != '"') {
>> sprintf(filecopy, "\"%.2047s\"", file);
>>} else {
>> strncpy(filecopy, file, 2047);
>>}
>> [...]
>> It should be:
>>
>> sp
>From :
> [...]
>char filecopy[2048];
>if (file[0] != '"') {
> sprintf(filecopy, "\"%.2047s\"", file);
>} else {
> strncpy(filecopy, file, 2047);
>}
> [...]
> It should be:
>
> sprintf(filecopy, "\"%.2045s\"", file);
> [...]
I'll admit to being old and grumpy, b
Thanks for the follow up. :-)
On Jul 5, 2007, at 3:52 PM, Micah Cowan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rich Cook wrote:
So forgive me for a newbie-never-even-lurked kind of question: will
this fix make it into wget for other users (and for me in the
future)?
Or do I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bruso, John wrote:
> Please remove me from this list. thanks,
Nobody on this list has the ability to do this, unfortunately (Wget
maintainership is separate from the maintainers of this list). To
further confuse the issue, [EMAIL PROTECTED] is actua
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rich Cook wrote:
> So forgive me for a newbie-never-even-lurked kind of question: will
> this fix make it into wget for other users (and for me in the future)?
> Or do I need to do more to make that happen, or...? Thanks!
Well, I need a chance to
So forgive me for a newbie-never-even-lurked kind of question: will
this fix make it into wget for other users (and for me in the
future)? Or do I need to do more to make that happen, or...? Thanks!
On Jul 5, 2007, at 12:52 PM, Hrvoje Niksic wrote:
Rich Cook <[EMAIL PROTECTED]> writes:
Rich Cook <[EMAIL PROTECTED]> writes:
> On Jul 5, 2007, at 11:08 AM, Hrvoje Niksic wrote:
>
>> Rich Cook <[EMAIL PROTECTED]> writes:
>>
>>> Trouble is, it's undocumented as to how to free the resulting
>>> string. Do I call free on it?
>>
>> Yes. "Freshly allocated with malloc" in the function d
Please remove me from this list. thanks,
John Bruso
From: Rich Cook [mailto:[EMAIL PROTECTED]
Sent: Thu 7/5/2007 12:30 PM
To: Hrvoje Niksic
Cc: Tony Lewis; [EMAIL PROTECTED]
Subject: Re: bug and "patch": blank spaces in filenames causes looping
On Jul 5, 2007, at 11:08 AM, Hrvoje Niksic wrote:
Rich Cook <[EMAIL PROTECTED]> writes:
Trouble is, it's undocumented as to how to free the resulting
string. Do I call free on it?
Yes. "Freshly allocated with malloc" in the function documentation
was supposed to indicate how to free the s
Rich Cook <[EMAIL PROTECTED]> writes:
> Trouble is, it's undocumented as to how to free the resulting
> string. Do I call free on it?
Yes. "Freshly allocated with malloc" in the function documentation
was supposed to indicate how to free the string.
"Virden, Larry W." <[EMAIL PROTECTED]> writes:
> "Tony Lewis" <[EMAIL PROTECTED]> writes:
>
>> Wget has an `aprintf' utility function that allocates the result on
> the heap. Avoids both buffer overruns and
>> arbitrary limits on file name length.
>
> If it uses the heap, then doesn't that open
Trouble is, it's undocumented as to how to free the resulting
string. Do I call free on it? I'd use asprintf, but I'm afraid to
suggest that here as it may not be portable.
On Jul 5, 2007, at 10:45 AM, Hrvoje Niksic wrote:
"Tony Lewis" <[EMAIL PROTECTED]> writes:
There is a buffer overfl
-Original Message-
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> Wget has an `aprintf' utility function that allocates the result on
the heap. Avoids both buffer overruns and
> arbitrary limits on file name length.
If it uses the heap, th
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> There is a buffer overflow in the following line of the proposed code:
>
> sprintf(filecopy, "\"%.2047s\"", file);
Wget has an `aprintf' utility function that allocates the result on
the heap. Avoids both buffer overruns and arbitrary limits on fil
t;\"%.2047s\"", file);
It should be:
sprintf(filecopy, "\"%.2045s\"", file);
in order to leave room for the two quotes.
Tony
-Original Message-
From: Rich Cook [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 04, 2007 10:18 AM
To: [EMAIL PROTECTED]
Sub
From: Rich Cook [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 04, 2007 10:18 AM
To: [EMAIL PROTECTED]
Subject: bug and "patch": blank spaces in filenames causes looping
On OS X, if a filename on the FTP server contains spaces, and the
remote copy of the file is newer than the local, th
On OS X, if a filename on the FTP server contains spaces, and the
remote copy of the file is newer than the local, then wget gets
thrown into a loop of "No such file or directory" endlessly. I have
changed the following in ftp-simple.c, and this fixes the error.
Sorry, I don't know how to u
21 matches
Mail list logo
