It looks like the same ones are coming around again. Once again I have been knocked out using 5.10.20. It would appear that I can upgrade to 5.10.38 to get around the problem. Is this the correct way though? Ralph is a test site, so going to a version that most people on Rosetta won't have may not give the desired answers to the programmers.

Right. 5.10.38 is not a fix to the problem. It's a work-around. The problem is with the application, which is where it needs to be fixed.

---

Reno, NV
Team: SETI.USA

Right. 5.10.38 is not a fix to the problem. It's a work-around. The problem is with the application, which is where it needs to be fixed.

wich is what we are helping by uploading data about crashes.

wich is what we are helping by uploading data about crashes.

Of course, but that doesn't answer the questions.

---

Reno, NV
Team: SETI.USA

wich is what we are helping by uploading data about crashes.

Of course, but that doesn't answer the questions.

then the answer would be that there is not enaugh data yet, or they are working on it, and in the same time theyre gathering as much data as possible about other things that could go wrong.

I would still appreciate answers from the project, rather than guessing.

Has this been fixed in the mini tasks and/or application yet?

Was this ever a problem with OSX version?

---

Reno, NV
Team: SETI.USA

When I said "we", I mainly meant David Anderson. I had to create more workunits for David Anderson to debug the client. Once he was able to get a work unit, he responded right away with the cause and checked in a fix. There are some non-boinc client related issues with mini also.

If you are experiencing this problem, manually remove the minirosetta_database directory in the slots directory.


This is David Anderson's reply:

"Here's what was happening:

The minirosetta app in Ralph unzipped an archive into its slot directory.
This archive (accidentally) included some .svn directories
(Subversion stuff) whose contents were flagged as read-only.

When the job finished or was aborted,
and the BOINC client tried to clean out the slot directory,
the delete of each of these files would fail.
The client would wait for 5 seconds and try again
(it does this because sometimes files are locked temporarily
by virus checkers or other disk-scan apps).
This would happen for each file, resulting in a 10-20 minute period
during which the client and Manager appear hung.

I made two changes that fix this (and hopefully avoid similar
problems in the future) as follows:

1) if a file delete fails with error ERROR_ACCESS_DENIED,
use SetFileAttributes() to clear the read-only flag, then try again.
2) Don't use the 5-second retry mechanism when clearing out
slot directories. These can contain unbounded numbers of files,
and this can lead to long periods where the client appears hung.

Rom, please back-port this to 5.10

-- DPA "

I would still appreciate answers from the project, rather than guessing.

Has this been fixed in the mini tasks and/or application yet?

Was this ever a problem with OSX version?

well that should answer your first question, posted by the staff, in this topic.
and well the second question im not aware of, so maybe you should some OSX users.

well that should answer your first question, posted by the staff, in this topic.
and well the second question im not aware of, so maybe you should some OSX users.

I am on the list, and I read it the day it was posted.

It answers neither question. The changes that DA made to BOINC were basically a work around, so that the flaw in the RALPH app would not longer cause problems with BOINC.

I'm asking if the fix to the RALPH app has been made yet.

---

Reno, NV
Team: SETI.USA

I just had one lock up my boinc and boincmgr, but thanks to DA's/project's explanation I was able to get around it by going into the slot directory and forcing the readonly attribute off, on the minirosetta_database directory and all its subirectories/files.

This wu was a reissue after some no-reply's, so I'd say some of the old "bad" wus are still floating around out there even if the project has gotten rid of the subversion files from later wus.

Edit: - the minirosetta_database directory was also not cleaned out of the slot dir after this wu had been reported; I had to remove it manually.

[XP Pro/ client 5.10.30]

Wow. A week now, and still no response from the project...at all.

It's odd that they ask for our participation, yet do not participate themselves.

Alpha testing is a two-way street.

---

Reno, NV
Team: SETI.USA

There's an updated version, 1.04. This version uses an updated database file that shouldn't cause any stalling issues. It should also remove the deprecated database(s). We'll likely add a bunch of test tasks next week if the initial runs look promising. So far, I don't see any errors which is a good sign.

---

Thanks for the info! Was this ever a problem for the Mac app? Or only windows?

---

Reno, NV
Team: SETI.USA

Thanks for the info! Was this ever a problem for the Mac app? Or only windows?

According to Message 3651, apparently for Mac OS too.

Peter

There's an updated version, 1.04. This version uses an updated database file that shouldn't cause any stalling issues. It should also remove the deprecated database(s). We'll likely add a bunch of test tasks next week if the initial runs look promising. So far, I don't see any errors which is a good sign.

I have one that is locked up.

score13_hb_envtest62_A_1opd__3299_1517_0

EDIT

It was stuck at 47% for several minutes. At about 30 minutes of computing time, it jumped from 47% to 100% completion.