Open ixeft opened 7 years ago
We just wrap the statvfs strict provided by libc. This is likely an issue with the type as it's declared there. Please open and issue there to discuss this and link back to this one.
yes, libc provide a flag to modify the type of those variable and allowing usage of more than 2Gio files (not 4Gio as I mentioned) by setting
#define _LARGEFILE_SOURCE
#define _LARGEFILE64_SOURCE
or even better :
#define _FILE_OFFSET_BITS
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
Ok, I just realized you wanted me to report a bug in i3status-rust, not in glibc :)
I just did that https://github.com/greshake/i3status-rust/issues/88
Thanks
Actually, susurrus meant that you should report a bug to Rust's libc, here: https://github.com/rust-lang/libc . That crate defines the FFI wrappers for all standard C structures.
I believe the solution here is to expose the stat*64
functions. for i3status to consume. I've therefore retitled this issue accordingly.
I'd love to have a safe wrapper for statvfs64
. Should I open a fresh issue (or PR) for that?
Sure. If you're motivated, create a PR for it.
Hello,
I'm not a rust programmer, but trying to compile https://github.com/greshake/i3status-rust and particularly this file : https://github.com/greshake/i3status-rust/blob/master/src/blocks/disk_space.rs I noticed that Statvfs::b_fsize where u32 instead of u64 creating a compilation error
using "as u64" I got the code compiling but now, with path bigger than 4Gio, I got an overflow getting wrong value of statvfs.f_bfree / statvfs.f_bsize (crazy big values)
Exemple of code that should demontrate the bug with 32bit system (Archlinux i686 - Intel Atom Z520)
Using glibc in C/C++ I would define _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE to solve this problem. not sure how to do so here.
Regards,