Jeremy Allison <jra@xxxxxxxxx> writes:
> On Fri, Feb 24, 2006 at 09:00:57AM -0500, derrell@xxxxxxxxx wrote:
>> Although I agree that the errno mapping table was poor, that scheme has
>> been used traditionally for mapping the errno values provided to
>> libsmbclient users. Applications depend on the errno values to determine
>> what went wrong (and some differ slightly from what would be returned by
>> Linux/Unix). I suggest that instead of removing this mapping table, we
>> either add a global variable (yuck!) that can determine whether to use the
>> traditional method or the new method, or find some other method of allowing
>> the traditional method to be selected by an application. We need to retain
>> the ability to return the existing errno mappings.
> Hmmmmm. Are you sure ? The scheme I changed it to will be more uniform, in
> that it will bounce through an NTSTATUS mapping and then to an errno
> number. If I can make sure that the mapping from DOSERR -> NTSTATUS -> errno
> returns the same ultimate errno value for 3.0.22 would that be sufficient ?
As long as the errno values returned post-change are the same as they were
pre-change, we're fine.
> I don't think there are any clients currently depending on the exact mappings
> we have from NTSTATUS -> errno, so I can always change the NSTATUS -> errno
> mapping to ensure the 2 stage translation comes out the same.
> I *really* want to move away from having DOSERR tables in the code if we
The issue isn't how the errno value gets set; it's just that given a certain
error condition, we must ensure that the value that's set in errno is the same
now as it was previously. If there's a way to map them without that table,
then there's no problem.
My preferred re-implementation would be to not set errno values until we're
about to return it to the user, i.e. do it at the top-most layer possible. At
the lower layers, just pass the NTSTATUS or DOS error values up the stack and
let the ultimate function which knows what a particular errno value really
means to a particular function, set errno. (Even this re-implementation
requires ensuring that the same errno values as previously get returned, but
allows documenting certain specific changes that would be appropriate to match
POSIX function definitions, for example.)
A product so extensively exported that the domestic supply is depleted