> That's complicated. Why not just:
> 1) create sam.ldb.lck || die "can't get lock"
> 2) fetch records, giving ldif1
> 3) launch editor, user does edits, giving ldif2
> 4) take diff of ldif1 and ldif2, and apply
> 5) unlock & exit
> This presumes that the clients aren't editing the same records as
> the admin is, but that's a separate issue.
Unfortunately that assumption isn't true. Normal operation of smbd
will edit records quite regularly (for example, when someone changes
their password). So the .lck file would protect against simultaneous
ldbedit sessions, but would not protect against edits of the same
attributes by smbd and ldbedit.
This is even more true for databases like wins.ldb, where all records
in the database are updated quite frequently.