Hi Ryan, On 26 Mar, 2013, at 5:29 AM, Ryan Schmidt <[email protected]> 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? >>> http://savannah.gnu.org/bugs/?21042 >> 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. > > _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
