From owner-freebsd-hackers Tue Mar 21 03:53:28 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA17660 for hackers-outgoing; Tue, 21 Mar 1995 03:53:28 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA17645 for ; Tue, 21 Mar 1995 03:53:02 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA14006; Tue, 21 Mar 1995 21:52:13 +1000 Date: Tue, 21 Mar 1995 21:52:13 +1000 From: Bruce Evans Message-Id: <199503211152.VAA14006@godzilla.zeta.org.au> To: hackers@FreeBSD.org, luigi@labinfo.iet.unipi.it Subject: Re: vipw feature (and fix) Sender: hackers-owner@FreeBSD.org Precedence: bulk >was actually changed. I thought it was me, but look at this fragment >of vipw.c where the check is made for changes to the password >file... > ... > if (stat(tempname, &begin)) > pw_error(tempname, 1, 1); > pw_edit(0); > if (stat(tempname, &end)) > pw_error(tempname, 1, 1); > if (begin.st_mtime == end.st_mtime) { > warnx("no changes made"); > pw_error((char *)NULL, 0, 0); > } > ... >so, if the changes to the password file are done faster than the st_mtime >resolution (is that one second ?), then no changes are assumed. >A better way would be needed for the check. On 2.1 the stat structure >actually uses "struct timespec" for the times. I propose to modify line >95 of vipw.c from > if (begin.st_mtime == end.st_mtime) { >to > if (begin.st_mtimespec == end.st_mtimespec) { This wouldn't help if the file system is the current or older ufs. The nanonseconds field is always 0. The problem could be fixed by adding `sleep(1)' before calling pw_edit() (assuming sleep(1) is guaranteed to take >= 1 second). Bruce