Re: #import future (summary and proposed solutions)

["Timothy J. Wood" <tjw at omnigroup dot com>]

On Saturday, January 25, 2003, at 10:37  PM, Zack Weinberg wrote:
> In a perfect world, file system designers would believe that stable
> inode numbers are a Good Thing.  As it is, they're basically useless
> (to FSF GCC; if Apple is prepared to guarantee that inode numbers are
> meaningful in all OSX-supported file systems, good on them).
  Is this because inodes get reused, or is there some other common 
problem?  If you store an fs identifier and the creation time and inode 
the extra info should be extremely good at disambiguating the inode (if 
gcc can ever run fast enough to have decent size file compiled, a 
header replaced and another compile started all within one second, you 
might have to worry about conflicts though :)

  The only arguments against inodes I see in Geoff's mail are:

> 9. Apple's implementation is known to have failure cases if the name 
> and inode
>    number just happen to match.
  Storing/comparing the creation time and some filesystem identifier 
would make this extremely unlikely

> 10. On Darwin, inode numbers are 32 bits, so there's no way they can be
>     permanently consistent when (for instance) NFS-mounting a 
> filesystem with
>     64-bit inode numbers.  Thus, saving them in a file is not a good 
> idea.
  As above, with the 32->64 bit extension for local inodes.

> 4. Save and restore enough state so that #import can work just as it 
> did before.
>    This requires saving absolute pathnames and/or device and inode 
> numbers.
>    These aren't guaranteed to be valid in the context where the PCH 
> file is used.
>    For instance, this would prevent building a PCH on one machine and 
> copying it
>    to a bunch of machines in a build farm.
  I don't see this as being a particularly compelling problem.  If you 
have some complicated build farm, rebuild the PCH on the build farm 
machines after the rsync.  Why should you transmit a huge PCH across 
the network anyway -- probably faster to build it again locally.  
Likewise the Developer Tools installer can rebuild the PCH's (why ship 
them on the CD -- just redundant information!)

  The overwhelmingly common case is the average developer writing code 
at one workstation on one local filesystem -- not the build farm or the 
dev tool maintainer or NFS or any of these other crazy edge cases.

  You could probably get rid of a lot of the edge cases by storing the 
inode, creation time and filesystem identifier of the PCH inside itself 
-- if any of that changed, just emit a warning to rebuild the PCH and 
treat it as a normal header.

-tim