Re: Small remote file transfer protocol adition

Pedro Alves
2008-01-29T15:21:30Z

>On Tue, Jan 29, 2008 at 04:28:31AM +0000, Pedro Alves wrote:
>> To be able support this, this proposal adds an optional field
>> to the reply packet:
>>
>> F$(retcode),$(remote_error),$(native_error);
>
>I don't like designing an interface that is going to have to show hex
>numbers to the user. They'd have to figure out that it was a target
>error number and look it up themselves.

We could state it clearly in the error message:

With native error:
Unkown remote I/O error. Target error was: 0xc0454054
Remote I/O error: $(strerror(host_error)). Target error was: 161

Without:
Unkown remote I/O error.
Remote I/O error: $(strerror(host_error)).

> Despite the localization
>issues involved, do you think it might be better to add an error
>string if you need the extra detail? We could put it in the
>attachment field.

I missed that field. I guess it would work too.

>Could you give me an example of a useful error code which does not map
>to one of the POSIX errors?

Most regular ones map correctly, but you lose detail.
Win32 codes are more finer grained then posix error codes.

E.g. for my preliminary patch:

case ERROR_ACCESS_DENIED:
case ERROR_SHARING_VIOLATION:
return FILEIO_EACCES;

case ERROR_FILENAME_EXCED_RANGE:
case ERROR_INVALID_DATA:
case ERROR_INVALID_PARAMETER:
case ERROR_NEGATIVE_SEEK:
return FILEIO_EINVAL;

Then, there's always the unexpected error that happens once,
and is hard to reproduce. winerr.h from w32api defines around
1500 error codes. Granted, most aren't file io related, but
I'm sure I'll miss one or two in the mapping. I'd rater see it
in the error message when it happens.

Currently, in this situation we get:
Unknown remote I/O error.

Not helpful, scarry, and these missing mappings tend to
not get fixed.

Would a patch that implements support for the attachment
field in an error reply be accepted, in principle?
I'll give it a try.

--
Pedro Alves