bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] [Bug-Wget] Issues with Metalink support


From: Jure Grabnar
Subject: Re: [Bug-wget] [Bug-Wget] Issues with Metalink support
Date: Wed, 7 May 2014 23:46:13 +0200

Hello,

I wrote two patches regarding this issue based on your suggestions.

The 1st one is crucial for retrieve_from_file() function: it fixes 2
memory corruption bugs.

The 2nd patch is more of an experiment than a real deal and is
intended to get some feedback. It changes parallel download to one
temporary file which is located in the selected directory. 

Before download starts it uses posix_fallocate() to allocate space and
mkstemp() for unique name. After download is completed it uses rename()
to rename temporary file to the final file name.

After posix_fallocate() each thread opens file with fopen("wb"). I
opted for fopen() rather than messing around with file descriptors
because I believe it's more portable. I don't know how Windows
would react to file descriptors and I don't have a proper Windows system
to test it out. Now, fopen("wb") means file, which was fallocate'd, is
truncated to zero but after first request from the thread, which is
reponsible for the last chunk, it would grow back to at least file_size
- chunk_size. I'm also not sure how devastating that is.

I'm attaching a handmade Metalink file which downloads a 50MB file for
testing purposes. Currently all threads connect to the same server and I
understand we don't support such behaviour but I guess 2-3 threads for
testing purpose don't hurt anyone. :)

I'm open for suggestions.

Regards,

Jure Grabnar

Attachment: 0001-Fix-bugs-causing-memory-corruption.patch
Description: Text Data

Attachment: 0002-Change-parallel-download-to-one-temporary-file-inste.patch
Description: Text Data

Attachment: 50mb.meta3
Description: Binary data


reply via email to

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