ports wget @1.14_2+ssl --continue issue
fsh3mve at gmail.com
Tue Mar 26 03:14:25 PDT 2013
On 26 Mar, 2013, at 5:29 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Mar 25, 2013, at 05:59, Martin Lambev wrote:
>> On 25 Mar, 2013, at 6:00 PM, Martin Lambev wrote:
>>> On 25 Mar, 2013, at 4:59 PM, Lawrence Velázquez wrote:
>>>> On Mar 25, 2013, at 4:17 AM, Martin Lambev wrote:
>>>>> I looked wget bug they mention this issue but could not find working solution altho they claim that this bug is fixed in recent version of wget?
>>>> Can you provide a link to this information?
>> Duplicate of this one: https://savannah.gnu.org/bugs/?21714
> Those bugs are about the file name being too long. You didn't show us the actual URL or filenames, but I'm guessing they're not extremely long.
>> Found another one: http://savannah.gnu.org/bugs/?38281 I think this one is more closer to my case, and it's recent so it's not solved.
>> But unfortunately the solution in this bug does not work on Mac (using tmp/ folder does not work either).
> I don't really understand the bug report. The reporter didn't use words to describe the problem, they just pasted a transcript. The transcript shows that running wget from its normal location in $PATH (wherever that happens to be) doesn't work, but that running /tmp/wget (why is wget there? did the user copy it there? did the user compile it there from source?) works. Given the limited information in the bug report, I can't explain that.
>> By accident I found out if I copy the file to external HDD ( FAT32 formatted) wget --continue can continue with the interrupted file no more "Cannot write to ‘foo.avi’ (Success)."
>> So I guess it's something to do with my Mac file system - Mac OS Extended (Journaled) FS???
>> Oh, here is worth mentioning that I'm using File Vault ( Full disk encryption) so my guess is that this is the main problem.
>> Because there is some changes in "Mountain Lion File Vault "
> I am also using File Vault 2 on a Mac OS Extended Journaled filesystem on Mountain Lion. Using "wget --continue http://apple.com/" I do not get an error.
I do not get error either using "wget --continue http://foo/file.ext" but only if the download is interupted and I try to continue using "wget --continue http://foo/file.ext"
Can you please give it a try? Start downloading something (program, audio, video) then interrupt it and then continue do you get the error?
> I suggest you work with the developers of wget to resolve this issue. I doubt it's a MacPorts-specific problem and the developers of wget will be better equipped to understand why their program would emit certain error messages.
More information about the macports-users