bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [PATCH] Support metalink:file elements with a "path/file"


From: Matthew White
Subject: Re: [Bug-wget] [PATCH] Support metalink:file elements with a "path/file" format
Date: Tue, 2 Aug 2016 10:06:42 +0200

On Sat, 30 Jul 2016 21:23:56 +0200
Matthew White <address@hidden> wrote:

> Hello!
> 
> I noticed that wget doesn't use the metalink:file element as the RFC5854 
> suggests.
> 
> https://tools.ietf.org/html/rfc5854#section-4.1.2.1
> 
> The RFC5854 specifies that the metalink:file could have a "path/file" format. 
> In this case wget should create the "path" tree and save the file as 
> "path/file", but it doesn't. Instead wget saves the file in the working 
> directory.
> 
> e.g. <file name="dirA/dirB/file.gz">
> 
> With this patch wget conforms to the RFC5854.
> 
> I made this patch working on the following branch:
> master (latest 20cac2c5ab3d63aacfba35fb10878a2d490e2377)
> git://git.savannah.gnu.org/wget.git
> 
> Let me know if this helps.

Hi,

After the suggestions of Tim, I fixed the patch (nice! fix the fix...). So, 
scratch the previous patch and use this one instead.

The function concat_strings() replaces the combination of malloc(), strlen(), 
and strcpy(). (Thanks Tim.)

The description now follows the style of the other patches. (Thanks again Tim!)

You may consider this patch a Bugfix:
* src/utils.c (unique_create, fopen_excl): cannot create a directory tree like 
"path/file".

The problem is that fopen_excl() doesn't create non-existing directories. What 
do you suggest?

Can we make this patch obsolete?

-- 
Matthew White <address@hidden>

Attachment: Bugfix-create-download-verify-Metalink-s-files-with-.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]