Where it is might be variable based on your Windows rev, but

I have windows 7, and mine is found in the directory named:

c:windowssystem32driversetc

the filename is

hosts

with no extension like .txt or .bin or anything. It is plain text, so you can open it with notepad, or any simple text editor.

In a search or find, look for name hosts.

put the line I quoted before, by itself on the last line of the file, not disturbing any other lines. If you want, you can put a comment line above your new line for later explanation, like:

# this entry is to fix a problem with rosetta
128.95.160.145 srv6.bakerlab.org

There is one or more spaces or tabs between the .145 and srv6, and finish the line with a RETURN

Save the file.

Now, go restart the upload of the stuck file(s). If your problem is the same as mine, they will work now.

Dave

If you're nervous about fooling with the file, copy it before editing, and then you can easily put it back the way you found it.

Dave this worked for me too, THANK YOU VERY MUCH!!!
I too removed the line afterwards.

I would suggest that it is likely that this one upload server simply has not completed it's upgrade yet, and that it will come back online soon. And therefore no action is required. When the server comes back online, BOINC will finally have a retry that works.

To do other things risks corrupting files which potentially effects your whole boat of tasks.

Aborting the transfer will be throwing away the work you've done, and the credit you've earned for that work.

...having said that, the suggestion below to hit an alternate upload server should be processed normally if you are comfortable achieving the redirection via the hosts file, etc.

I just got in from the rig after being offshore for 2 weeks and found a few hundred work units hung like this on my machines. I applied the hosts file fix and I have been able to upload the stuck processed work units this way, so the advice given above works. As for me, I think I will move Back to Seti for a while and let Rosetta work through their issues with the move. It would have been nice if they had posted advanced warning of the move, since I work in remote areas and leave my systems crunching while at work. I would have set Seti to run while the move was going on before I left for the rig.

Vista wont let me change the hosts file. I'll have to do some research on this.

Edit: OK opened Notepad as Admin and removed the read only status from hosts and added the entry, but my outstanding WU still wont upload and it's been over a week now. May have to abort it.

Anyone else having this problem still?

The server status page says everything is up and running so it shouldn't be happening.

---

Peter.
Toronto, Canada

OK regarding my previous post...I made the mistake of entering a '#' before the line....don't do that.

Posted this just in case anyone else is as dumb as me....;-)

---

Peter.
Toronto, Canada

I've made the hosts file change, which seems AOK :-

C:>ping srv6.bakerlab.org
Pinging srv6.bakerlab.org [128.95.160.145] with 32 bytes of data:

but I still can't upload, getting this info :-

09/01/2012 15:22:55 | rosetta@home | [fxd] starting upload, upload_offset -1
09/01/2012 15:22:55 | rosetta@home | Started upload of ab_11_29__optpps_T5781_optpps_03_09_35686_181472_0_0
09/01/2012 15:22:55 | rosetta@home | [file_xfer] URL: http://srv6.bakerlab.org/rosetta_cgi/file_upload_handler
09/01/2012 15:22:56 | rosetta@home | [file_xfer] http op done; retval -224 (file not found)
09/01/2012 15:22:56 | rosetta@home | [file_xfer] file transfer status -224 (file not found)
09/01/2012 15:22:56 | rosetta@home | Project file upload handler is missing
09/01/2012 15:22:56 | rosetta@home | Backing off 7 hr 35 min 0 sec on upload of ab_11_29__optpps_T5781_optpps_03_09_35686_181472_0_0

Any ideas if I should just wait, or if I have some other problem?

Many thanks!

Quote: "It would have been nice if they had posted advanced warning of the move, since I work in remote areas and leave my systems crunching while at work. I would have set Seti to run while the move was going on before I left for the rig.[/quote]"

They did give advance notice on January 2nd. It was on the main page under "news"

"Jan 02, 2012
The hardware hosting the Rosetta@Home project is being moved from one datacenter to another on the UW campus. We are using this disruption to update the sagging, aging gear that runs the project. All of this will result in a few days of down time. We will work to keep the outage to a minimum, but you migh want to grab enough work for a 4-5 day period. We appreciate your patience, interest and continued contributions to our research. -KEL"

For those of use who had to alter the hosts file in order to get outstanding WU's to upload and then removed the alteration, will future uploads work OK?

---

Peter.
Toronto, Canada

Hmmm I changed the upload_url's from srv6 to srv4 in client_state.xml and they've all now uploaded AOK ( As a software engineer I wasn't too worried about inadvertently borking the file ).

I think despite my seemingly successful change to the hosts file, it was still trying to upload to srv6 (if I tried the srv6 url in a browser it gave a DNS failure, if I changed it to srv4 I got some xml sent back that looked promising).

Time to undo the hosts file change... Thanks for the helpfull hints!

For those of use who had to alter the hosts file in order to get outstanding WU's to upload and then removed the alteration, will future uploads work OK?

Answering my own question, they do. One just uploaded from here.

---

Peter.
Toronto, Canada

Update from here:

It's still doing it - I just had to fake out hosts once more for a unit that couldn't resolve host name, and that unit was created less than 24 hours ago. So you might want to keep that mod in hosts, or maybe leave it there but comment it out (by putting the # character as the first character on the line: that way you can turn it back on real easy in the future, in need be.

# i am a comment
# and so is the next line
# 128.95.160.145 srv6.bakerlab.org

To make the file work, take away the # in front of 128.......

Oh, and it so happens I have some ubuntu. In my ubu systems hosts is found as

/etc/hosts

and I make the presumption that this would be standard on most any unix flavored host, but am not sure. Look there first. I also had some ubuntu units stuck, and this boosted them along just as Winders did.

And sorry, I log in as admin, so permissions are usually not an issue for me, but could be for many folks.

For those who missed it, my orginal suggestion is in my post of " Posted 8 Jan 2012 1:30:23 UTC ", in this thread and in the top pinned thread in Number Crunching, too.

Dave

That's a good idea to keep it there, dormant so to speak.

I log in as an Admin but Notepad still has to be run as Administrator in Vista or Win 7.

---

Peter.
Toronto, Canada

That's a good idea to keep it there, dormant so to speak.

I log in as an Admin but Notepad still has to be run as Administrator in Vista or Win 7.

Not on my pc it didn't...I don't know why but I even did it over a VNC connection and it worked just fine. I have Win7 Ultimate 64bit on the far end but Win7 Ultimate 32bit on this end.

That's strange. It failed here when I tried without running NP as Admin.

---

Peter.
Toronto, Canada

I think, Win7 (and maybe vista too) have configurable setting(s) for just how intense the user protection is (UAC, or some such), and systems may have a settable amount of strictness is in force. Thus I think all of these may be true, given your system config. Don't ask me how to change it, but I think it's out there somewhere.

Dave

You're right. Mine is default but others may have adjusted theirs. Google can be of help there with UAC settings. I don't mind as long as I know what to do in future.

---

Peter.
Toronto, Canada

Does anyone know if this has been sorted or ever will be sorted at bakerlab's end? I used the 'hosts' workaround on my local PCs but I might not have access to some of the remote machines under my account for a long time and if they're waiting to upload those results before downloading new ones then those machines are lost, at least for the foreseeable future.

Danny

---

Does anyone know if this has been sorted or ever will be sorted at bakerlab's end?

As transient indicates, this particular issue should be fixed now, and the srv6.bakerlab.org domain name should point to a live server.
Please let us know if you're still seeing problems, keeping in mind that it might take a little while for the DNS changes to propagate to all the ends of the internet.

Thanks for bearing with us during these recent server move hiccups.

I had more than 25 hanging WU of rising and yesterday on January 10 they raised all without having to do specially at all. I suppose that they have arranged it from R@H.
The sorrow is that they do not give any news and we always remain with the reasonable doubt.
Happy Year 2012!

Thanks for the update all - that's good news.

---

I still have 17 tasks for 257 total hours of WUs that won't upload!

I tried the hosts workaround but it did not solve the problem.
I watched inside client_state.xml but apparently none of my Rosetta WUs points to srv6.

I tried a lot of 'update project' and 'retry' until some seconds ago but nothing worked.


I want to add that 'update project' fails too and that my stats on this website says that last time I contacted server was 3 Jan 2012 20:36:32 UTC.

The WUs have a report deadline expired on Jan 9.
Should I abort them?