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

fs::metadata - Value too large for defined data type #30050

Closed
szagi3891 opened this issue Nov 25, 2015 · 9 comments · Fixed by #31551
Closed

fs::metadata - Value too large for defined data type #30050

szagi3891 opened this issue Nov 25, 2015 · 9 comments · Fixed by #31551
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@szagi3891
Copy link

When i try get info abouth file with function : .metadata()
https://doc.rust-lang.org/std/fs/struct.DirEntry.html#method.metadata

I get an error:
{ repr: Os { code: 75, message: "Value too large for defined data type" } }

This file is in the directory is the size : 17848195008 byte.

@sfackler
Copy link
Member

What OS are you on?

@szagi3891
Copy link
Author

My platform : x86, linux (debian 8)

@alexcrichton
Copy link
Member

Yeah it looks like you're trying to open a 17GB+ file in a 32-bit binary but we currently aren't using the LFS functions which allow opening files larger than 4GB on 32-bit Linux platforms.

I think this should be a pretty easy change to make, just gotta tweak some structs here and ther!

@alexcrichton
Copy link
Member

triage: I-nominated

Seems like a good thing to categorize on behalf of the libs team though. This will have ramifications on the std::os module (e.g. the stat structure exposed) which may be good to discuss.

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Nov 25, 2015
@cuviper
Copy link
Member

cuviper commented Nov 26, 2015

This discussion was just rekindled on the internals LFS thread too.

I'd like to take this on, if no one else is already doing it.

@alexcrichton
Copy link
Member

@cuviper feel free!

@cuviper
Copy link
Member

cuviper commented Dec 3, 2015

Just a small update, I did get a little time to work on this over the holiday, but it's not pull-worthy yet. There's some overlap with #30175 though in fixing up dirent, where LFS wants dirent64, so I think it will make sense for me to wait for that to merge and then build on top.

@alexcrichton
Copy link
Member

We talked about this in the libs triage meeting yesterday, and the conclusion was that I'll draft up an RFC to write about this as it'll have ramifications on std::os::raw

@alexcrichton
Copy link
Member

I've now opened an RFC which I hope will help enable us to fix this issue in a "backwards-compatible" fashion

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 13, 2016
This commit is an implementation of [RFC 1415][rfc] which deprecates all types
in the `std::os::*::raw` modules.

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md

Many of the types in these modules don't actually have a canonical platform
representation, for example the definition of `stat` on 32-bit Linux will change
depending on whether C code is compiled with LFS support or not. Unfortunately
the current types in `std::os::*::raw` are billed as "compatible with C", which
in light of this means it isn't really possible.

To make matters worse, platforms like Android sometimes define these types as
*smaller* than the way they're actually represented in the `stat` structure
itself. This means that when methods like `DirEntry::ino` are called on Android
the result may be truncated as we're tied to returning a `ino_t` type, not the
underlying type.

The commit here incorporates two backwards-compatible components:

* Deprecate all `raw` types that aren't in `std::os::raw`
* Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method
  accessors of all fields. The fields now returned widened types which are the
  same across platforms (consistency across platforms is not required, however,
  it's just convenient).

and two also backwards-incompatible components:

* Change the definition of all `std::os::*::raw` type aliases to
  correspond to the newly widened types that are being returned on each
  platform.
* Change the definition of `std::os::*::raw::stat` on Linux to match the LFS
  definitions rather than the standard ones.

The breaking changes here will specifically break code that assumes that `libc`
and `std` agree on the definition of `std::os::*::raw` types, or that the `std`
types are faithful representations of the types in C. An [audit] has been
performed of crates.io to determine the fallout which was determined two be
minimal, with the two found cases of breakage having been fixed now.

[audit]: rust-lang/rfcs#1415 (comment)

---

Ok, so after all that, we're finally able to support LFS on Linux! This commit
then simultaneously starts using `stat64` and friends on Linux to ensure that we
can open >4GB files on 32-bit Linux. Yay!

Closes rust-lang#28978
Closes rust-lang#30050
Closes rust-lang#31549
bors added a commit that referenced this issue Feb 14, 2016
This commit is an implementation of [RFC 1415][rfc] which deprecates all types
in the `std::os::*::raw` modules.

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md

Many of the types in these modules don't actually have a canonical platform
representation, for example the definition of `stat` on 32-bit Linux will change
depending on whether C code is compiled with LFS support or not. Unfortunately
the current types in `std::os::*::raw` are billed as "compatible with C", which
in light of this means it isn't really possible.

To make matters worse, platforms like Android sometimes define these types as
*smaller* than the way they're actually represented in the `stat` structure
itself. This means that when methods like `DirEntry::ino` are called on Android
the result may be truncated as we're tied to returning a `ino_t` type, not the
underlying type.

The commit here incorporates two backwards-compatible components:

* Deprecate all `raw` types that aren't in `std::os::raw`
* Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method
  accessors of all fields. The fields now returned widened types which are the
  same across platforms (consistency across platforms is not required, however,
  it's just convenient).

and two also backwards-incompatible components:

* Change the definition of all `std::os::*::raw` type aliases to
  correspond to the newly widened types that are being returned on each
  platform.
* Change the definition of `std::os::*::raw::stat` on Linux to match the LFS
  definitions rather than the standard ones.

The breaking changes here will specifically break code that assumes that `libc`
and `std` agree on the definition of `std::os::*::raw` types, or that the `std`
types are faithful representations of the types in C. An [audit] has been
performed of crates.io to determine the fallout which was determined two be
minimal, with the two found cases of breakage having been fixed now.

[audit]: rust-lang/rfcs#1415 (comment)

---

Ok, so after all that, we're finally able to support LFS on Linux! This commit
then simultaneously starts using `stat64` and friends on Linux to ensure that we
can open >4GB files on 32-bit Linux. Yay!

Closes #28978
Closes #30050
Closes #31549
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants