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. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
