Sorry for using this forum but there are R@H tasks and these fora are quite popular and maybe someone knows the answer.

The problem is as following:

I have finished several tasks and they show their status as "transferring". However, the manager does not show any result files to send back to the servers.

The problem is *probably* a result of "one click too far" - double run of portable version of the manager (I can't *install* an original one on this machine).

To make the story short: the results are present in their projects directories and seem to be fine.

Unfortunately, the manager does not see them. When you check logs in stdoutdae.txt you see
access path, like projects/docking.cis.udel.edu/name_of_file not found.

Originally the manager tries only once and then "forgets" about files to transfer (but their WU status remains "transferring"). I coped with that manually editting client_state.xml (change status flag from 0 to 1 in a proper file's section), however the manager still doesn't see the files - you get the file not found log and that's all.

What bugs me is I couldn't find any string with access path or sth that could be corrupted. Everything in client_state.xml looked fine.

Last things:
The results are not reported.

What is interesting, one of original *sets of files* to transfers was not corrupted and got reported - that makes me think there is some access path responsible for all the files generated by one WU which I have missed.

Second thing: further WUs have been downloaded from the servers and sent back without any problem.

I see two possibilities:

1) BOINC manager is looking for the files in a wrong place. No idea why, probably some string got corrupted/deleted.
I have tried to place a projects folder in different places - maybe I should try more? :)

Is there any other file where such things like access paths are stored?

2) BOINC manager sees the files, but treats them as corrupted and doesn't give a proper report in its logs. Names of the files are correct, I havent seen anything strange according to their sizes (both actual and in client_state).. It is possible that the MD5 is not valid. :/

Any help will be appreciated. I have seen a couple of reports about this mistake here and there but no solution was found.

I can only suggest that you get some tasks, suspend network activity, complete the tasks, and study how those .out file look in the BOINC control files.

If there were an MD5 problem, you would have a message saying that, and the tasks would be marked as invalid in some way and removed from your task list.

What version of BOINC? And what type of OS are you running?

---

Rosetta Moderator: Mod.Sense

I can only suggest that you get some tasks, suspend network activity, complete the tasks, and study how those .out file look in the BOINC control files.

That's precisely what I thought and did. :) I've did some further tasks and took a look into client_state.xml. After that switching the status from 0 to 1 was obvious. Unfortunately, I couldn't see the rest of the solution.

If there were an MD5 problem, you would have a message saying that, and the tasks would be marked as invalid in some way and removed from your task list.

What version of BOINC? And what type of OS are you running?

Oh, good to know that.

The version in question is 5.10.45, tweaked as a portable app (it should not perform a regular installation which would interfere in an OS). OS is Windows 2000.

Being honest, I don't count on finding a solution before the WU deadline :) however I wanted to give a hint about this problem on a popular BOINC forum and at least gather some data for others affected by this bug in future.