On 02/18/2013 01:33 PM, Eric Sandeen wrote:
XFS recently defaulted to allowing > 32 bit inode numbers, and
btrfs can let inode numbers creep past 2^32 as well.
While most applications don't care one bit about st_ino returned from a stat() call,
the sad fact is that you'll get EOVERFLOW from stat32 if the inode number is too big
to fit in 32 bits, even if you just wanted to get the file size.
[snip]
Anyway, if you want to check your package(s) and maybe make them
64-bit-stat safe, the perl script above might help. It's more than just
-DFILE_OFFSET_BITS=64, since you'll need to be sure not to overflow any large values
you get back from stat64 etc.
Might be nice to get out ahead of this before, say, btrfs comes into wide use. I
don't know if there could be any more of a formal effort in this direction?
p.s. here's a list of what was on my system that turned up hits:
[snip list of several dozen packages that are affected]
It would be useful to have a "backward compatibility" LD_PRELOAD shared
library which intercepts the caller of stat32, and sets .st_ino to 0,
without generating EOVERFLOW, whenever the actual inode number exceeds
32 bits. This would allow the *option* of continued operation
(postponing the work of portability enhancements) for the vast majority
of packages which do use stat() but do not inspect .st_ino.
--