This proposal is more or less exactly what I would suggest.

Now if someone will only write it. :)

Perry

Missing - presumed fed. writes:
> Chris Jones sez:
> /* 
>  * 1) User runs chfn.
> 
> Cool.  A generic tmp file, not ptmp, is created.
> 
>  * 
>  * 2) Sysadmin edits user's passwd info.
>  *
> 
> Vipw.  Creates /etc/ptmp.
> 
>  * 3) User finishes editing his info, and hits :wq.
> 
> User gets "/etc/ptmp:  Password file busy, try again later", OR
> it goes into a waiting game if the user wants it to.
> 
>  * 
>  * 4) Now what?  I guess chfn should take out a lock, and then verify
>  * that its idea of the previous values matches what's currently in
>  * passwd; otherwise, it errors out.  But this could cause some confusion
>  * on the part of the user...
> 
> This is really getting absurd here (general comment; not to catch any
> one person).
> 
> The ONLY program that should ever create ptmp as an active lock AND HOLD
> IT FOR ANY AMOUNT OF TIME should be vipw.  Other programs which need
> ptmp should batch the input (i.e. wait until the user's done) and only
> create ptmp when the data is ready, i.e.
> 
> 	1.	user edits data
> 	2.	user quits
> 	3.	chsh/chfn/passwd filters data from vi tmp file (NOT ptmp!)
> 		and mixes existing passwd data with requested change data.
> 		_THIS_ is what comprises ptmp for a very short period of time.
> 	4.	ptmp moves to master.passwd
> 	5.	old compat passwd file is derived from master.passwd
> 	6.	pwd_mkdb is run
> 
> ...or am I missing something?