On Mon, Feb 18, 2013 at 03:33:33PM -0600, 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. > > I have a script (http://sandeen.net/misc/summarise_stat.pl) which > Greg Banks wrote; it can check a path or list of filenames for > binaries which contain non-64bit-safe stat calls. A quick look over > my F18 install finds the situation to be only slightly in favor of > executables using 64-bit variants: > > # ./summarize-stat.pl /usr > 270229 91.5% are scripts (shell, perl, whatever) > 22633 7.7% don't use any stat() family calls at all > 913 0.3% use 32-bit stat() family interfaces only > 1335 0.5% use 64-bit stat64() family interfaces only > 73 0.0% use both 32-bit and 64-bit stat() family interfaces > > and it's not just weird obscure packages: > > # ./summarize-stat.pl `rpm -ql sendmail` > 69 78.4% are scripts (shell, perl, whatever) > 2 2.3% don't use any stat() family calls at all > 17 19.3% use 32-bit stat() family interfaces only > > 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? Eric, I've read this email and the summarise_stat script a couple of times, and I admit I'm confused. (1) Just ensuring the code is compiled with -DFILE_OFFSET_BITS=64 is sufficient to ensure the 32 bit stat will never be called, right? (2) If my code never mentions st_ino, it's safe? [I assume the answer to this is *no* because you seem to be saying that -EOVERFLOW could be returned from an innocent-looking stat call, even if the code never looks at st_ino.] (3) For my code that uses st_ino, I need to ensure this is never assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)? (4) Is doing (1) & (3) sufficient to fix all stat32-related problems in my code? (5) With -DFILE_OFFSET_BITS=64, is st_ino a 64 bit value? Also a note that the current man page for stat(2) doesn't mention this problem, doesn't mention that EOVERFLOW could be returned in this surprising situation, and also has an example that casts st_ino to a long which I assume would be unsafe behaviour on a 32 bit architecture. These are all bugs that the man-pages maintainers would no doubt be interested in. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
