A bad task will always upload. What it normally won't do is be calculated without an error message. Not uploading is caused mostly by the server not being available, or another glitch between your computer and the project. I asked for the Event Log around such a botched upload, mind giving that?
The Event Log should give a reason why the upload does not go through.
This one is apparently a good wu that won't upload. Any event log that would reflect it going to upload has been lost do to restarts.
. . . it just sits on the transfer screen, doing absolutely nothing.
The wingman shows it as in progress also, it probably won't upload for him either.
A bad task will always upload. What it normally won't do is be calculated without an error message. Not uploading is caused mostly by the server not being available, or another glitch between your computer and the project. I asked for the Event Log around such a botched upload, mind giving that?
The Event Log should give a reason why the upload does not go through.
This one is apparently a good wu that won't upload. Any event log that would reflect it going to upload has been lost do to restarts.
. . . it just sits on the transfer screen, doing absolutely nothing.
The wingman shows it as in progress also, it probably won't upload for him either.
Old messages from the Event Log are preserved across restarts in a file called 'stdoutdae.txt' in your BOINC data directory. Messages even older than that are in a file called 'stdoutdae.old' in the same directory.
Alternatively, on the Transfers tab, highlight the transfer you're talking about and click 'Retry Now' - thus generating a new set of messages to show us.
I have seen one situation like this, and advised others how to deal with it - but I'd like to see the actual evidence to confirm it's the same issue, before giving you what might turn out to be an inappropriate suggestion.
It may only be one WU for you, but it seemed significant enough to you at the time for you to comment (I paraphrase) "me too" on somebody else's report, and - unlike him - for you to stick with the conversation.
Until we get some idea of what is causing the issue you were moved to write about, none of us knows whether it has any significance. I was recently asked to look at a file transfer problem that a couple of CPDN members had encountered: that revealed a serious security flaw in the version of BOINC under test last week, and its replacement (today) by BOINC v7.0.60
I'm not saying that you've at risk from a security flaw: just that we'll never know unless we follow up your (shall we say) oddity of an upload.
I'm very surprised that 'Retry Now' doesn't result in a log entry: I'd expect even default (minimal) logging to produce something like
SETI@home 02/04/2013 23:13:00 Started upload of 29no12ah.31626.48902.206158430220.10.208_0_0
SETI@home 02/04/2013 23:13:03 Temporarily failed upload of 29no12ah.31626.48902.206158430220.10.208_0_0: connect() failed
SETI@home 02/04/2013 23:13:03 Backing off 10 hr 42 min 42 sec on upload of 29no12ah.31626.48902.206158430220.10.208_0_0
in the event log. In that case I don't have to worry, because I know that the upload server that should be receiving the file is on a removal truck between the top and the bottom of the hill at Berkeley - that's outside my control.
But I have no such glib explanation of why your upload is stuck, which is why I'm intrigued by it.
RE: A bad task will always
)
This one is apparently a good wu that won't upload. Any event log that would reflect it going to upload has been lost do to restarts.
. . . it just sits on the transfer screen, doing absolutely nothing.
The wingman shows it as in progress also, it probably won't upload for him either.
RE: RE: A bad task will
)
Old messages from the Event Log are preserved across restarts in a file called 'stdoutdae.txt' in your BOINC data directory. Messages even older than that are in a file called 'stdoutdae.old' in the same directory.
Alternatively, on the Transfers tab, highlight the transfer you're talking about and click 'Retry Now' - thus generating a new set of messages to show us.
I have seen one situation like this, and advised others how to deal with it - but I'd like to see the actual evidence to confirm it's the same issue, before giving you what might turn out to be an inappropriate suggestion.
Richard: On the transfer
)
Richard:
On the transfer tab, it just sits there with upload: pending
. . . retry now doesn't result in a log entry.
Still nothing from the wingman. . . I'm waiting to see if he notices it and aborts it.
It's only one WU and really not all that important.
It may only be one WU for
)
It may only be one WU for you, but it seemed significant enough to you at the time for you to comment (I paraphrase) "me too" on somebody else's report, and - unlike him - for you to stick with the conversation.
Until we get some idea of what is causing the issue you were moved to write about, none of us knows whether it has any significance. I was recently asked to look at a file transfer problem that a couple of CPDN members had encountered: that revealed a serious security flaw in the version of BOINC under test last week, and its replacement (today) by BOINC v7.0.60
I'm not saying that you've at risk from a security flaw: just that we'll never know unless we follow up your (shall we say) oddity of an upload.
I'm very surprised that 'Retry Now' doesn't result in a log entry: I'd expect even default (minimal) logging to produce something like
in the event log. In that case I don't have to worry, because I know that the upload server that should be receiving the file is on a removal truck between the top and the bottom of the hill at Berkeley - that's outside my control.
But I have no such glib explanation of why your upload is stuck, which is why I'm intrigued by it.