I have had a system crash on my computer due to a driver problem after installation of XP SP2. When this happened it seems that Boinc reset my projects and lost the climateprediction work unit, but the \'missing\' work unit is still on my computer but does not reappear on the Boinc application.

How can I reattach the work unit stored on my computer such that this can be completed instead of lost ?

I use a Dell Inspiron 9100 with P4 3GHz Dual processor, XP Home Edition with SP2, 512MBytes RAM and currently run Boinc 4.05 and projects SETI@home and ClimatePredictions.net

hmmm, it sounds like the client_state.xml file in boinc got messed up. There may be a backup file (named "client_state_prev.xml") that you could experiment with copying over?

> hmmm, it sounds like the client_state.xml file in boinc got messed up. There
> may be a backup file (named "client_state_prev.xml") that you could experiment
> with copying over?
>

No can do, as the client_state file is saved as the 'backup' client_state_prev before the client_state file is written to as a result of workunit activities.

Besides, the workunit zip files that are downloaded are protected in the client_state file through checksums and file signatures. Perhaps this means the work unit is 'lost' forever and should be removed from my computer, or perhaps the climateprediction administrators could create some sort of file sequence that could be used to reload the workunit into the Boinc application ?

I believe the client_state file was not necessarily corrupted, but rather suffered from a Boinc Reset that cleared this file for all workunits - I also lost around 20 SETI@home workunits as well.

Right, got the same problem. Two modells lost one machine due to crash of pc.
Can´t the admin recreate the signatures and checksums?



> > hmmm, it sounds like the client_state.xml file in boinc got messed up.
> There
> > may be a backup file (named "client_state_prev.xml") that you could
> experiment
> > with copying over?
> >
>
> No can do, as the client_state file is saved as the 'backup' client_state_prev
> before the client_state file is written to as a result of workunit
> activities.
>
> Besides, the workunit zip files that are downloaded are protected in the
> client_state file through checksums and file signatures. Perhaps this means
> the work unit is 'lost' forever and should be removed from my computer, or
> perhaps the climateprediction administrators could create some sort of file
> sequence that could be used to reload the workunit into the Boinc application
> ?
>
> I believe the client_state file was not necessarily corrupted, but rather
> suffered from a Boinc Reset that cleared this file for all workunits - I also
> lost around 20 SETI@home workunits as well.
>
>
>

> hmmm, it sounds like the client_state.xml file in boinc got messed up. There
> may be a backup file (named "client_state_prev.xml") that you could experiment
> with copying over?


Similar problem, different question :

Something similar happened to me too while attaching to S@H - system freeze and had to reinstall BOINC. Both client_state(_prev).xml didn't contain those two (it's a 2-CPU machine) Climate models anymore so they are lost for this run.

Now the question :

Wouldn't it make sense for a project with long running work units to find a way to invalidate them? If it works like it does now, the first chance that those models will be delivered again will be in about one year so the result might arrive in maybe two years - needs a lot of patience for the project scientists :-/

> Wouldn't it make sense for a project with long running work units to find a
> way to invalidate them? If it works like it does now, the first chance that
> those models will be delivered again will be in about one year so the result
> might arrive in maybe two years - needs a lot of patience for the project
> scientists :-/

Where BOINC returns an error to the server then this is recorded and the WU can be re-sent.

The problem is with WUs that have been lost in virtual space for whatever reason, and it is just this lack of information that creates the problem. For example, we have just had a question raised on the PHP board about whether it would be possible to run a WU without any internet connection at all (apart, of course from the download at the start and upload at the end). It wasn't explained why, but there was presumably a good reason for the query. Although the project only treats as active machines trickling in the past two weeks, there are those who run on machines that don't normally connect to the internet and those who want to run the model on slow machines not running 24/7 (which is the reason for the very long deadline).

I suppose that given the very large number of permutations of the experiment, and the impracticability of covering them all, the scientists are fairly relaxed about losing a few.