Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Nov 1999 15:40:43 -0500 (EST)
From:      Kelly Yancey <kbyanc@posi.net>
To:        Bill Studenmund <wrstuden@nas.nasa.gov>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Portable way to compare struct stat's?
Message-ID:  <Pine.BSF.4.05.9911161512530.87356-100000@kronos.alcnet.com>
In-Reply-To: <Pine.SOL.3.96.991116104358.25522K-100000@marcy.nas.nasa.gov>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911161512530.87356-100000>