You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 3455 Reporter: administrator Status: acknowledged Resolution: open Priority: normal Severity: feature Category: otherlibs Monitored by: marc
Bug description
Full_Name: Marc Herbert
Version: 3.08.2
OS: linux
Submission from: lns-vlq-38-lyo-82-253-157-250.adsl.proxad.net (82.253.157.250)
type stats = {
st_dev : int; (* Device number )
st_ino : int; ( Inode number *)
My favourite POSIX.1 bible (Lewine) leaves st_ino and st_dev types
"private" to the implementation. On my linux machine for instance
st_dev is u64 and st_ino is u32. So I would say there is a
sign/overflow issue here.
Granted, most users probably don't have more than 1 billion file on
their filesystems, but filesystesm may use high bits to store meta-data (like
OCaml does with integers), and they may use whatever numbering they
like. But the worst is that some huge filesystems (for instance
distributed ones) may already reach this number of inodes.
"One potential solution would be to extend the inode number to be 64
bits, and then encode the block group information explicitly into the
high bits of the inode number. [...] Another potential solution to
this problem is to utilize inode numbers starting from the end of the
inode space"
Yes, Unix.stat API is not well-designed w.r.t. this issue. No obvious fix: if
st_ino and st_dev are really unspecified integer types, there is no
corresponding Caml integer type to use. Leave this a feature wish, but it
doesn't appear urgent at all. XL, 2005-09-24
Original bug ID: 3455
Reporter: administrator
Status: acknowledged
Resolution: open
Priority: normal
Severity: feature
Category: otherlibs
Monitored by: marc
Bug description
Full_Name: Marc Herbert
Version: 3.08.2
OS: linux
Submission from: lns-vlq-38-lyo-82-253-157-250.adsl.proxad.net (82.253.157.250)
Unix.stats
http://caml.inria.fr/ocaml/htmlman/libref/Unix.html#TYPEstats
type stats = {
st_dev : int; (* Device number )
st_ino : int; ( Inode number *)
My favourite POSIX.1 bible (Lewine) leaves st_ino and st_dev types
"private" to the implementation. On my linux machine for instance
st_dev is u64 and st_ino is u32. So I would say there is a
sign/overflow issue here.
Granted, most users probably don't have more than 1 billion file on
their filesystems, but filesystesm may use high bits to store meta-data (like
OCaml does with integers), and they may use whatever numbering they
like. But the worst is that some huge filesystems (for instance
distributed ones) may already reach this number of inodes.
Actually, even such a "small" filesystem as linux' ext2/3 may be an
issue in the future, see for instance:
http://e2fsprogs.sourceforge.net/extensions-ext23/
"One potential solution would be to extend the inode number to be 64
bits, and then encode the block group information explicitly into the
high bits of the inode number. [...] Another potential solution to
this problem is to utilize inode numbers starting from the end of the
inode space"
And also:
http://lists.freebsd.org/pipermail/freebsd-current/2004-January/018647.html
"So the reality is that the very large scalable file systems hash
larger identifiers into 32-bit values for local representation."
"ino_t probably does need to get bumped to 64-bit on FreeBSD at some point,"
This was somewhat previously posted in comp.lang.ml
http://groups.google.com/groups?selm=ct3c0k%24p49%241%40wolfberry.srv.cs.cmu.edu
http://groups.google.com/groups?selm=ct3pvb%24su9%241%40wolfberry.srv.cs.cmu.edu
PS: the slow performance of the bug search engine makes it almost unusable.
The text was updated successfully, but these errors were encountered: