Follow-up Comment #12, bug #17877 (project findutils):
> If files are identified by the path, then you can hash the
> path. If you use a good 64-bit hash the chance of collision
> is practically zero. That's good enough.
Yes. And this solution is actually practical on pure 64bit
archs only. On 32bit and dual archs it's not practial, because
legacy apps (those compiled without largefile support) will
get an EOVERFLOW for stat if the inode number doesn't fit in
32 bits. This is irrespective of whether the app actually
would use st_ino or not.
So in fact 64 bit inode numbers would _break_ a lot of
currently installed systems. This is not a theoretical
possibility, I've had bug reports in this area.
Any other solutions?
> I may sound a bit impatient here, but it's impatience for a
> reason. Knowledge of file serial numbers must be hardwired
> into thousands of programs. We can't change them all. If you
> have to support inodes by some inefficient means, then I'm
> afraid that's what you'll have to do. (Or, if you prefer,
> you can warn users of these file systems that they will
> break lots of programs. :-)
Currently I have report of exactly 1 (one) application,
that breaks. That is an alpha version of find, for which
a solution is actually in the works (see gnulib-bugs ml).
So I think your impatience is rather unwarranted.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?17877>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils
