From owner-freebsd-hackers Tue Nov 16 12:40:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id D336B14DC5 for ; Tue, 16 Nov 1999 12:40:45 -0800 (PST) (envelope-from kbyanc@posi.net) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from localhost (kbyanc@localhost) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with ESMTP id PAA87906; Tue, 16 Nov 1999 15:40:43 -0500 (EST) Date: Tue, 16 Nov 1999 15:40:43 -0500 (EST) From: Kelly Yancey X-Sender: kbyanc@kronos.alcnet.com To: Bill Studenmund Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Nov 1999, Bill Studenmund wrote: > On Mon, 15 Nov 1999, Kelly Yancey wrote: > > > > > Is there a portable method for determining if the contents of two struct > > stat's are identical? I believe there is not. The problem is that while > > What exactly are you trying to do? i.e. why are you comparing the struct > stat's? > Basically just determine whether any field of the structure has changed (ie, if any of the file's metadata has changed). But the tricks are that a) not all file systems implement a ctime value b) even on systems that do implement ctime fields, Posix only requires 1 second resolution (unlike FreeBSD which was smart enough to use timespecs for nanosecond resolution :) ) c) the method has to work on all (or most) operating systems that implement the stat, fstat, and lstat calls. I thought memcmp() to be the correct solution except that spare fields in the structure are filled with garbage (kernel stack contents), and who knows what values might be stored in the padding between fields for alignment. Using memcmp yields false positives then. Unfortunately, a quick perusal of the OpenBSD source tree indicates that it (and most likely NetBSD) also have the problem. Which leads to the dillema, how to tell with any reasonable accuracy whether 2 stat structures are the same on a given OS. I'm beginning to think that the only way is a kludge: one routine per OS which only checks the fields defined on that OS. This will greatly limit portability due to the cost of maintainability :( I'm hoping that someone knows a better way. For the list: while I was checking OpenBSD's kern_descrip.c to see whether they zeroed the memory first, I noticed that they had the following check that my 3.3-stable system does not: [ ... ] /* Don't let non-root see generation numbers (for NFS security) */ if (suser(p->p_ucred, &p->p_acflag)) ub.st_gen = 0; [ perform copyout ... ] Is this a legitimate concern or paranoia? I see that we don't bother in -current with it either. Thanks, Kelly -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message