... Then we can spend the rest of the weekend wondering why a "file not found" problem gets reported in the message log as "URL not found".
I presume you are referring to these two lines
Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] Couldn't start upload of p2030.20100614.G46.20-00.29.C.b0s0g0.00000_3344_0_2
Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] URL http://einstein-dl.aei.uni-hannover.de/cgi-bin/file_upload_handler: not found
which doesn't actually say that a URL wasn't found. I interpret it to mean that the file_upload_handler (whose URL was given) has reported back a 'not found' message for the file that it was told to upload - the file whose name was given in the first line.
If this wasn't the log entry you were referring to then please excuse this interruption.
In your most recent message, I would be fairly confident that the change of from 4 to 5 and the addition of the extra two lines, particularly would have been needed to make it all succeed. Thanks very much for taking the trouble to diagnose and explain the problem so clearly.
It was that log entry, and your explanation sounds fine, just not really what one would expect at first sight.
And yes, I included the changes Richard suggested in his answer to my post, so I
- deleted 3x 7 lines from
- inserted 3 lines in there
- changed to 5 once in
- inserted those 2 lines once in as well
Of course I forgot to make a copy of the client_state.xml before the changes, but it went fine, lucky me :D
... Then we can spend the rest of the weekend wondering why a "file not found" problem gets reported in the message log as "URL not found".
I presume you are referring to these two lines
Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] Couldn't start upload of p2030.20100614.G46.20-00.29.C.b0s0g0.00000_3344_0_2
Do 08 Dez 2011 20:49:55 CET | Einstein@Home | [file_xfer] URL http://einstein-dl.aei.uni-hannover.de/cgi-bin/file_upload_handler: not found
which doesn't actually say that a URL wasn't found. I interpret it to mean that the file_upload_handler (whose URL was given) has reported back a 'not found' message for the file that it was told to upload - the file whose name was given in the first line.
Yes, those were the lines.
I still think that's a very confusing error message - guilty of misdirection, at the very least. It seems to be very odd to go to all the trouble of opening up an http connection, and then letting the remote server discover a rather basic fact about the local filing system. In my day job, I think it's better practice to ensure that I have all the tools and materials I'm going to need for a callout, present and correct before I leave the house.
I certainly wouldn't have been able to diagnose Saenger's problem from the log message if I hadn't worked through the diagnosis on my own machine first - and a debug log which doesn't allow one to diagnose a problem from the information contained in the log, could be better written.
The example I posted from another project did indeed have a trailing / on the upload handler url - but that hadn't prevented that project from accepting many thousands of valid upload files.
I did also specifically link the earlier thread here, and point out that Einstein's url doesn't have a trailing / - but that got no reply at all.
I just had another one of those, this time only one part failed with the memorization of its upload.
Corrected it the same way as last time, worked again like a charm, but still frustrating to have to do it.
RE: RE: ... Then we can
)
It was that log entry, and your explanation sounds fine, just not really what one would expect at first sight.
And yes, I included the changes Richard suggested in his answer to my post, so I
- changed to 5 once in
- inserted those 2 lines once in as well
Of course I forgot to make a copy of the client_state.xml before the changes, but it went fine, lucky me :D
Grüße vom Sänger
RE: RE: ... Then we can
)
Yes, those were the lines.
I still think that's a very confusing error message - guilty of misdirection, at the very least. It seems to be very odd to go to all the trouble of opening up an http connection, and then letting the remote server discover a rather basic fact about the local filing system. In my day job, I think it's better practice to ensure that I have all the tools and materials I'm going to need for a callout, present and correct before I leave the house.
I certainly wouldn't have been able to diagnose Saenger's problem from the log message if I hadn't worked through the diagnosis on my own machine first - and a debug log which doesn't allow one to diagnose a problem from the information contained in the log, could be better written.
I've made a post to the
)
I've made a post to the BOINC_dev-mailing list about this:
http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2011-December/018274.html
Grüße vom Sänger
RE: I've made a post to the
)
And Richard posted the problem a month ago (Sun Nov 13 09:10:31 PST 2011) in the boinc_alpha-list, but got no useful answer there:
http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2011-November/016103.html
Only answer by DA was this ;) :
Grüße vom Sänger
The example I posted from
)
The example I posted from another project did indeed have a trailing / on the upload handler url - but that hadn't prevented that project from accepting many thousands of valid upload files.
I did also specifically link the earlier thread here, and point out that Einstein's url doesn't have a trailing / - but that got no reply at all.
I just had another one of
)
I just had another one of those, this time only one part failed with the memorization of its upload.
Corrected it the same way as last time, worked again like a charm, but still frustrating to have to do it.
Grüße vom Sänger
Anyone knows whether this bug
)
Anyone knows whether this bug is bound to specific client versions?
BM
BM
RE: Anyone knows whether
)
Mine here is 6.12.34, running under ubuntu 10.04LTS.
But it seems to have been others as well.
Grüße vom Sänger
I just had the same prob over
)
I just had the same prob over @Albert.
Grüße vom Sänger
