Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unix st_ino and st_dev overflow (> 30 bits) #3455

Closed
vicuna opened this issue Feb 3, 2005 · 3 comments
Closed

Unix st_ino and st_dev overflow (> 30 bits) #3455

vicuna opened this issue Feb 3, 2005 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Feb 3, 2005

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.

@vicuna
Copy link
Author

vicuna commented Sep 24, 2005

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Feb 5, 2006

Comment author: anonymous

I think it would be safe to assume no local filesystem will ever use more than 64bits for any of those types.

So, putting aside the issue of galaxy-wide filesystems, could mapping those types to ocaml's int64 provide a decent fix?

@nojb
Copy link
Contributor

nojb commented Mar 15, 2019

Closing since it is not an issue on 64-bits, there is no obvious fix for 32-bit systems, and does not appear urgent at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants