Menu

#1169 curl -LOJC- http://url doesn't resume as expected

closed-later
5
2013-06-21
2012-12-06
john
No

curl version:
curl 7.28.1 (x86_64-pc-win32) libcurl/7.28.1 OpenSSL/1.0.0j zlib/1.2.7 WinIDN libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz

windows 7 x64 home premium

I like to use curl to download large files, and rely on the resume to restart download if it breaks. Nowadays many of the urls dont include the actual filename anymore, eg downloading from ubuntuone the url looks like http://ubuntuone.com0pYiteewbQWcKU70E

previously I used curl -LOC- http://url and it worked fine, except the resulting filename not always correct. trying to use curl -LOJC- http://url almost works except you lose resume capability as shown below.

I would like to use the J option to get correct filename written but without losing resume support.

I note that varying order of options leads to varying results, but experimentation gives this as best so far unless I've missed something.

C:\Users\john\Downloads\d>curl -LOJC- http://ubuntuone.com/0pYiteewbQWcKU70E
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Warning: Refusing to overwrite 3DKDirect-Burn.exe: Fil
e exists
0 1175M 0 890 0 0 750 0 19d 00h 0:00:01 19d 00h 1037
curl: (23) Failed writing body (0 != 890)

John

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2012-12-10

    Right, since it doesn't know the actual target file name until way down the line it is a problem indeed...

     
  • Daniel Stenberg

    Daniel Stenberg - 2012-12-13
    • status: open --> open-confirmed
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-05-21
    • status: open-confirmed --> closed-later
    • Group: --> not_used
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-05-21

    Thanks for the report. No help and a lack of time, still like this after 6 months in the tracker. This issue has now been added to the KNOWN_BUGS document as problem #81. I'll close this entry here now. It may be re-opened again in the future.