Bill Sommerfeld wrote:

> > Using "test $$dest -ef ${__objdir}" would be bit more efficient.  The
> > following seems to work for a few test cases:
> 
> In general, I don't trust -ef to not have occasional false positives
> (for instance, consider the case of NFS to a remote device with a Very
> Large filesystem, It's not possible to have a 32-bit
> unique-within-filesystem identifier if there are more than 2**32 files
> on the box.  NFS will make do as best it can, but will no doubt have
> to generate duplicate-appearing inode numbers every now and then).

A quick scan shows at least:

	cp(1), sh(1), csh(1), ksh(1), pax(1), pwd(1), du(1), make(1),
	patch(1), rdist(1), tail(1), vi(1), install(1), lpr(1), sendmail(8),
	sup(1), and ypserv(8)

have the same problem.  Some of these do combine link count, uid/gid and
mode checks, but that's still false-positive prone.  If we really have
filesystems that have more that 2**32 files then there's a _lot_ more to
worry about than a dud objdir.

It looks like file handles should be unique (right?) but you can't get
a filehandle unless you are root.  Is this restriction because of the
directory access check bypass?  If so maybe when getfh() is run as
non-root we could do the full directory access check.  Or is there a
more sinister reason not to give out file handles to non-root processes?

Simon.