samba-cvs.cvs
[Top] [All Lists]

Re: svn commit: samba r13668 - in trunk/source/libsmb: .

Subject: Re: svn commit: samba r13668 - in trunk/source/libsmb: .
From:
Date: Fri, 24 Feb 2006 16:37:13 -0500
Jeremy Allison <jra@xxxxxxxxx> writes:

> On Fri, Feb 24, 2006 at 09:00:57AM -0500, derrell@xxxxxxxxx wrote:
>> 
>> Jeremy,
>> 
>> 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
> can.

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.)

Cheers,

Derrell


-- 
democracy n.
  A product so extensively exported that the domestic supply is depleted

<Prev in Thread] Current Thread [Next in Thread>