Samba login

okuyamak at okuyamak at
Fri Nov 3 08:37:01 GMT 2000

>>>>> "JA" == Jeremy Allison <jeremy at> writes:
JA> Have you taken a look at the re-design of the number
JA> of stat calls for the Miami conference ? This should
JA> help - the reason we have to do a stat call on an incoming
JA> path is that we have to map the case insensitive name given
JA> to smbd to a case sensitive name used by UNIX.

The following are what I could find easily:

  calls sys_stat() then calls open() without any change on

./source/lib/smbrun.c: setup_stdout_file()
  calls sys_stat() then calls open() without any change in 'outfile'.

./source/ilb/util_unistr.c: load_unicode_map()
  calls sys_stat() then calls open() without any change on

I need to take more time, to find others.

JA> SIGUSR1 is now used for message passing. The USR1/2 debugging
JA> code has now been removed.

This, I did not know. And I think your news is good news for me.

>> # And if you take look at code more carefully, you'll find
>> # many bugs in non-major path, which also will cause unstability.
JA> Specifics please ! This is how we get things fixed. I know
JA> you've been sending in bug fixes and I've been integrating
JA> them as fast as I get them - thanks. If you know of more
JA> bugs please pass them along to us.

Ofcourse, as soon as I found one, with fix. But there's one thing
preventing me from doing quickly.  Buggy code is hard to read, for
"Purpose of the function is un-understandable" in most cases.
# The fact that I could not understand the code, have high possibility
# of I being dumb, for Samba is actually WORKING code, in one hand.

By the way, does that 'fix' include something like 'SYMBOLYZING'?

For example in ./source/smbd/reply.c, there are many
kind of codes.

If you check carefully about parameter of transfer_file(), first
parameter '0' was file descriptor, and not something of simple
index, length, or NULL ( yes, there's lots of place where 0 is being
used instead of NULL ).

These 'direct number' also prevent many programmers from
understanding. And you can find many, in Samba code.

JA> Well, the 2.2 code structure is actually *cleaner*
JA> than the 2.0.x codebase (IMHO - and Andrew's I think).

I agree. It became lot clearner.
But for me, it's not enough(^^;) You'll see the reason below.

JA> Most of the new functionality is being added in the RPC
JA> code which is completely orthoganal to the network
JA> layer and stat work you are describing here.

Good news for me. But network layer is not clearly divided from RPC
layer ( for some of the RPC layer directly changes input buffer ).
And THAT's one of the point we should fix first.

It's "Interface between units" that's causing hard to tune. Not
simply individual units. And because of this Interface unclearness,
fix to them is being hard, especially when code is changing.

I think we should first face this fact.

best regards,
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan. Co.

More information about the samba-technical mailing list