Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm using wget to mirror some files across from one server to another. I'm using the following command:

wget -x -N -i http://domain.com/filelist.txt

-x = Because I want to keep the directory structure

-N = Timestamping to only get new files

-i = To download a list of files from an external file, one on each line.

Small files such as one i'm testing that's 326kb big download just fine.

But another that is 5gb only downloads 203mb and then stops (it is always 203mb give or take a few kilobytes)

The error message shown is:

Cannot write to âpath/to/file.zipâ

(I'm not sure why there are the strange characters before and after. I am using Putty in Windows and this may or may not have something to do with it, so I left them in. I presume not though.).

The full response is as follows: (I have replaced paths, ip and domain name)

--2012-08-31 12:41:19-- http://domain.com/filelist.txt Resolving domain.com... MY_IP Connecting to domain.com|MY_IP|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 161 [text/plain] Server file no newer than local file âdomain.com/filelist.txtâ

--2012-08-31 12:41:19-- http://domain.com/path/to/file.zip Connecting to domain.com|MY_IP|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 5502192869 (5.1G) [application/zip] The sizes do not match (local 213004288) -- retrieving.

--2012-08-31 12:41:19-- http://domain.com/path/to/file.zip Connecting to domain.com|MY_IP|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 5502192869 (5.1G) [application/zip] Saving to: âdomain.com/path/to/file.zipâ

3% [====>
] 213,003,412 8.74M/s in 24s

Cannot write to âdomain.com/path/to/file.zipâ

It doesn't seem to make any difference if the path directory already exists or is created on the fly.

Does anyone have any idea why it stopping and how I can fix it?

Any help with be most appreciated.

EDIT: I have also tried just doing a wget, no file input and renaming the file. This time it downloads a little over 3gb and then gives the same cannot write error.

wget -x -N http://domain.com/path/to/file.zip -O files/bigfile.zip
share|improve this question
    
Do you have any special characters in your path? –  JMeterX Aug 31 '12 at 12:21
    
Does it work as expected if you type "cd /tmp && " before the command? –  Eric DANNIELOU Aug 31 '12 at 12:24
    
Is your disk full? –  Jenny D Aug 31 '12 at 12:26
    
The disk is definitely not full and there are no special characters. Although the length of the path is 87 characters, some Googling has shown some problems with long names (the file name is only 29 characters though) It fails in just the same way in tmp. –  Freeze Dried Pop Aug 31 '12 at 12:34
    
@FreezeDriedPop Since your file name is relatively long you could change using the -O option so wget -O test.zip http://link –  JMeterX Aug 31 '12 at 12:37
show 2 more comments

3 Answers

If it starts saving a large file and writes 203 MB of it, I would suspect that you have either a full file system on the receiving end or the network connection is timing out.

You can use df -h on the receiving server to see if the filesystem is full

Check out this answer for timeout issues with wget:

http://stackoverflow.com/questions/2291524/does-wget-timeout

Also, re-try the transfer that failed and omit the -N timestamp option

Also, run ulimit -a to see if there is a file size limit on the receiving server

share|improve this answer
    
I'm no expert but I think it is running CentOS 6. Also i'm not sure how to check the character representation. Although it does start downloading and downloads other smaller files just fine, so I don't think that sounds like the problem. –  Freeze Dried Pop Aug 31 '12 at 12:48
    
Do the files it succeeds in downloading have ANY funny characters in their names? –  DisgruntledUser Aug 31 '12 at 13:17
    
No, no strange characters at all, unless a dot is a strange character e.g. "megapack_4.11.zip". But again i've tried it just with the name "bigfile.zip" and the same problem occurs. –  Freeze Dried Pop Aug 31 '12 at 13:24
    
Perhaps it is only Putty that is set to a different char representation than UTF-8 –  DisgruntledUser Aug 31 '12 at 13:27
    
Yeah I really don't think that's the problem, I just mentioned it as I was copy and pasting from Putty. The real problem the cannot write to. –  Freeze Dried Pop Aug 31 '12 at 13:37
show 1 more comment
up vote 0 down vote accepted

Finally figured it out and it was a space issue. It's a problem with 1and1 Cloud Server's, more about it here: http://www.mojowill.com/geek/1and1-dynamic-cloud-server-disk-allocation/

share|improve this answer
add comment

It is a problem with long URL. I faced it too. So, I used bit.ly and shortened the url. Works like a Charm!

share|improve this answer
    
Are you sure? It seems unlikely that the download will start and break off at some point when the issue is related to the URL, which is used only at the very start of the transaction. –  Felix Frank Jun 21 at 12:57
    
Yes. I had the same problem. Try it. –  Namchester Jun 22 at 10:42
    
I think the problem is with linux not able to recognize the long url. –  Namchester Jun 24 at 18:59
    
I suppose you mean the shell? Because the kernel is most definitely innocent of this failure. Even for the shell it's not likely, but if it was the case, again, the download could not even start - the shell would error out before even forking the prospective wget process. –  Felix Frank Jun 24 at 20:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.