I think one cannot just put the file where it belongs because BOINC remembers the download failure and tries to re-download, thus overwriting it again and creating the 0-sized file because download fails again.
Nope, not correct. If BOINC wants to download a file and finds a pre-existing 'good' copy (matching MD5 checksum) it will accept it and skip the download attempt. I do this all the time and there is no problem.
All you need to do is stop BOINC, remove any 'bad' copies (zero length is obviously 'bad') and deploy the missing files into the EAH project folder. It doesn't matter where you get the files from - one of the available mirrors listed in the state file or just pinch them from a local machine that already has copies, if you have such a machine. When you restart BOINC and try to get new work, it will find the missing files it needs and give you the 'download skipped' message for each one.
OK, I copied 5 files from another machine to the one with the http error.
Files and sizes:
cufft... 27883kB
...-cuda32-nv301.exe 15843kB
...-cuda32-nv301.exe-dbhs.dev 32kB
...-cuda32-nv301.exe-db.dev 14kB
einsteinbinary-BRP4_1.00_graphics_windows_intel86.exe 19236kB
(is also reported as http error)
Restarted BOINC then
cufft and BRP4_1.00:graphics... have a size of 0 bytes after the next (failed) download.
So the mechanism that detects that these files are still present fails.
Are the problem files listed in the state file as having some sort of error? If so, just stop BOINC and edit the state file with a plain text editor to remove the complete .... block that describes the file (including the error). If BOINC starts up and reads the state file and sees that some file supposedly has an error, it will just delete the 'good' copy of the file immediately and try to download it again, just perpetuating the error. If it doesn't see the error designation, it wont delete the file so that when it realises that it needs the file, it will discover the 'good' copy and not try to download it.
I know this works - I've done it at least 20 times today on different machines - not because I have to but simply to save unnecessary downloads of the same files over and over on multiple machines. Browse your state file - it should be pretty obvious as to what exactly is causing BOINC to discard your manually placed good copies. I'm assuming you are absolutely certain that you are placing the right files in the correct location. Some of the names are very close and easily confused.
The condition seems to have been resolved, both hosts suffering from it were able to download all that they need to operate now. They were able to do so all by themselves, no tinkering with client state files or copying required.
Are the problem files listed in the state file as having some sort of error? If so, just stop BOINC and edit the state file with a plain text editor to remove the complete .... block that describes the file (including the error). If BOINC starts up and reads the state file and sees that some file supposedly has an error, it will just delete the 'good' copy of the file immediately and try to download it again, just perpetuating the error. If it doesn't see the error designation, it wont delete the file so that when it realises that it needs the file, it will discover the 'good' copy and not try to download it.
I know this works - I've done it at least 20 times today on different machines - not because I have to but simply to save unnecessary downloads of the same files over and over on multiple machines. Browse your state file - it should be pretty obvious as to what exactly is causing BOINC to discard your manually placed good copies. I'm assuming you are absolutely certain that you are placing the right files in the correct location. Some of the names are very close and easily confused.
The problem seems to be solved by admins, switching now to the 'calculation error' thread
RE: I think one cannot just
)
Nope, not correct. If BOINC wants to download a file and finds a pre-existing 'good' copy (matching MD5 checksum) it will accept it and skip the download attempt. I do this all the time and there is no problem.
All you need to do is stop BOINC, remove any 'bad' copies (zero length is obviously 'bad') and deploy the missing files into the EAH project folder. It doesn't matter where you get the files from - one of the available mirrors listed in the state file or just pinch them from a local machine that already has copies, if you have such a machine. When you restart BOINC and try to get new work, it will find the missing files it needs and give you the 'download skipped' message for each one.
Cheers,
Gary.
OK, I copied 5 files from
)
OK, I copied 5 files from another machine to the one with the http error.
Files and sizes:
cufft... 27883kB
...-cuda32-nv301.exe 15843kB
...-cuda32-nv301.exe-dbhs.dev 32kB
...-cuda32-nv301.exe-db.dev 14kB
einsteinbinary-BRP4_1.00_graphics_windows_intel86.exe 19236kB
(is also reported as http error)
Restarted BOINC then
cufft and BRP4_1.00:graphics... have a size of 0 bytes after the next (failed) download.
So the mechanism that detects that these files are still present fails.
Are the problem files listed
)
Are the problem files listed in the state file as having some sort of error? If so, just stop BOINC and edit the state file with a plain text editor to remove the complete .... block that describes the file (including the error). If BOINC starts up and reads the state file and sees that some file supposedly has an error, it will just delete the 'good' copy of the file immediately and try to download it again, just perpetuating the error. If it doesn't see the error designation, it wont delete the file so that when it realises that it needs the file, it will discover the 'good' copy and not try to download it.
I know this works - I've done it at least 20 times today on different machines - not because I have to but simply to save unnecessary downloads of the same files over and over on multiple machines. Browse your state file - it should be pretty obvious as to what exactly is causing BOINC to discard your manually placed good copies. I'm assuming you are absolutely certain that you are placing the right files in the correct location. Some of the names are very close and easily confused.
Cheers,
Gary.
The condition seems to have
)
The condition seems to have been resolved, both hosts suffering from it were able to download all that they need to operate now. They were able to do so all by themselves, no tinkering with client state files or copying required.
Have a good weekend, everybody!
RE: Are the problem files
)
The problem seems to be solved by admins, switching now to the 'calculation error' thread
Oh, and btw, thanks Gary. I
)
Oh, and btw, thanks Gary. I just vaguely knew what to look for in the state file but not how to manipulate it.
Cheers.