On 04/ 7/11 03:11 PM, Danek Duvall wrote:
Shawn Walker wrote:
On 04/ 7/11 02:54 PM, Jon Aimone wrote:
<TRANSFER_MOD_E Apr 7 20:47:25> file protocol error: code: 37
<TRANSFER_MOD_E Apr 7 20:47:25> URL:
'file:///net/10.129.133.13/export/ds02/d534/workspace/ja123687/repo/Exalogic/stage1/solaris_repo/repo/publisher/solaris/pkg/library
0.000000libtool -0.000000libltdl/1.5.22
The OS' underlying errno is passed through for NFS repositories. In
this case, the error number is ECHRNG Channel number out of range,
which is a bit bizarre.
That suggests there was some sort of unexpected failure on the NFS
server side.
I think this is more likely the curl error:
/usr/include/curl/curl.h: CURLE_FILE_COULDNT_READ_FILE, /* 37 */
Doh, yes. We do pass through OS errno in other cases though. But I had
forgotten libcurl could bubble up vague messages like this.
Note that we often get a framework error 7 which is also there, as
CURLE_COULDNT_CONNECT. I wonder if we shouldn't just put this enum into a
dict like httplib.responses so that we can print a more understandable
error message.
Of course, what would be *really* useful here is what file couldn't be
read; I'm not sure if curl/pycurl returns that bit of information, though
it's possible we can reconstruct it from the information we have on our
side.
The file that couldn't be read should be the URL shown in the error.
Annoyingly, libcurl doesn't expose what underlying reason it couldn't
read the file. It will throw a general error for almost any read failure.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
