#789534 lua-posix: posix.stat fails given a very large inode number

Package:
lua-posix
Source:
lua-posix
Description:
posix library for the Lua language
Submitter:
Norman Ramsey
Date:
2015-07-05 21:42:03 UTC
Severity:
normal
#789534#5
Date:
2015-06-21 23:47:06 UTC
From:
To:
Dear Maintainer,

I was using Lua function posix.stat to check to ensure a given
pathname is a directory, when surprisingly, it failed with an error
message.  Given the same pathname, stat(1) succeeds.  I suspect that
the issue is that the inode number is too large for lua_pushinteger().
I'm not sure why the inode number is so large; df reports only 391M
inodes (it's a 2TB drive).

Here's a little evidence; I would have expected posix.stat to return
a table here:

: nr@homedog ; lua -lposix -e 'print(posix.stat [[/red1/ipod-for-vw]])'
nil     /red1/ipod-for-vw: Value too large for defined data type        75

: nr@homedog ; lua -v
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio

: nr@homedog ; /usr/bin/stat /red1/ipod-for-vw
  File: ‘/red1/ipod-for-vw’
  Size: 8192            Blocks: 24         IO Block: 4096   directory
Device: 821h/2081d      Inode: 5908674496  Links: 186
Access: (0775/drwxrwxr-x)  Uid: (32074/      nr)   Gid: ( 6202/      nr)
Access: 2015-06-21 17:52:57.483419546 -0400
Modify: 2015-06-21 19:38:52.703941495 -0400
Change: 2015-06-21 19:38:52.703941495 -0400
 Birth: -

: nr@homedog ; df -i -h /red1
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sdc1        391M  179K  391M    1% /red1
#789534#10
Date:
2015-06-22 00:54:30 UTC
From:
To:
It turns out that for an XFS filesystem of more than 1TB, 64-bit
inode numbers are normal.  Recompiling the source with

#define _FILE_OFFSET_BITS 64

might solve the problem.
#789534#17
Date:
2015-07-05 20:46:11 UTC
From:
To:
Hi Enrico,

Thanks for the heads up on this.

Unfortunately, this is a limitation of Lua 5.1 (a 12 year old codebase, albeit maintained with bug fixes until 3 years ago), which has but a single numeric type, where even integers are represented inside Lua itself as a 64bit double; i.e. only 53 bits of precision, which is not large enough to accurately contain any 64bit integers that use the 11 MSB.

Moving debian up to Lua 5.3, which represents integers as a 64bit type where available (either int or long, as required) and floating point values separately as doubles, will provide luaposix with enough bits to represent pid_t, ino_t and other 64bit types on modern machines using a lua_Integer.

I am not sure whether keeping up compatibility with PUC Rio Lua 5.1 is such a good idea given this, and several other shortcomings that testing has revealed. That said, an ugly solution with Lua 5.1 compatibility might be to wrap all potentially 64bit C types used by luaposix in a Lua userdata that displays as a hex-string and can round-trip the C->Lua->C API successfully.  Patches along those lines are most welcome :)

For sure, fiddling with _FILE_OFFSET_BITS won’t help in the least.

Cheers,
Gary
#789534#22
Date:
2015-07-05 21:33:43 UTC
From:
To:
Thanks for the quick answer!

I guess a non-fix would be to detect, on the C side, the "overflow"
and give an accurate error message.  Better than nothing.

Working around Lua 5.1 limitations is not something we can tackle IMO.

Lua 5.3 will eventually land in Debian (I've already a package for it,
it needs just some testing).  I'll also update lua posix as a
consequence.

Best,