smbpasswd fails due to race condition

[Charles Goff]

I installed Samba 2.2.8 on a new DS25 Alpha, running VMS 7.3-2.
 
It is mostly working, but I cannot run the "smbpasswd" command
successfully, nor does manually editing the smbpasswd.dat file get me
very far.  Seems only first entry in file is useable.  The format of the
line entries seems standard (colon separated and ends with a colon).
 
Running "smbpasswd" to add entries creates a "race condition".  Running
it through Swat does the same.  I can run the smbpasswd file to
"disable" or "enable" the first user in the smbpasswd.dat file, but it
doesn't appear to be modifying the file.  There does seem to be
functionality, as it will not even try to create the account if the
account is not already on the VMS server.
 
See examples below:
 
$ mc smbpasswd -a macmans
New SMB password:
Retype new SMB password:
                        startsmbfilepwent_internal: too many race
conditions opening file /samba_root/private/smbpasswd.dat
startsmbfilepwent_internal: too many race conditions creating file
/samba_root/private/smbpasswd.dat
add_smbfilepwd_entry: unable to open file.
Failed to add entry for user macmans.
Failed to modify password entry for user macmans
 
$ mc smbpasswd -a ziolol 
New SMB password:
Retype new SMB password:
                        User ziolol does not exist in system password
file (usua
lly /etc/passwd). Cannot add account without a valid local system
user.
Failed to modify password entry for user ziolol
 
 
I installed the C compiler (6.5), and fully compiled it, but no
difference.  I've played with protections and ownership, but no
difference.  Seems like the "race condition" may have something to do
with opening, editing, and closing the file using different threads.
 
Below is some output from a HP OpenVMS "Guide to DECthreads" manual on
the subject of "race conditions".
 
3.6.2 Avoiding Race Conditions
A race condition occurs when two or more threads perform an operation,
and the result of the operation depends on unpredictable timing factors;
specifically, when each thread executes and waits and when each thread
completes the operation. 
For example, if two threads execute routines and each increments the
same variable (such as x = x + 1), the variable could be incremented
twice and one of the threads could use the wrong value. For example:
Thread A increments variable x. Thread A is interrupted (or blocked, or
scheduled off), and thread B is started. Thread B starts and increments
variable x. Thread B is interrupted (or blocked, or scheduled off), and
thread A is started. Thread A checks the value of x and performs an
action based on that value. 
The value of x differs from when thread A incremented it, and the
program's behavior is incorrect. 
Race conditions result from lack of (or ineffectual) synchronization.
To avoid race conditions, ensure that any variable modified by more than
one thread has only one mutex associated with it, and ensure that all
accesses to the variable are made after acquiring that mutex. 
 
 
 
Thanks in advance for any assistance,
Regards,  
Charles Goff