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

Fix for FreeBSD issues #62

Closed
wants to merge 2 commits into from
Closed

Conversation

malinoskj2
Copy link

Fix for #60
Swapped out some of the FreeBSD statfs struct's field sizes with what they had in the man page. Test's are passing for me on 2 machines both running FreeBSD 12 w/ ZFS.

@valpackett
Copy link
Owner

valpackett commented Jun 7, 2019

This does not sound like #60, #60 was about integer overflow in the free space fields.

Looks like the libc crate now has this statfs struct, and both freebsd12 and freebsd11 versions (!) so they're finally doing something about rust-lang/libc#570 :)

https://github.com/rust-lang/libc/blob/master/src/unix/bsd/freebsdlike/freebsd/freebsd12/mod.rs

So instead of changing the statfs definition here, I'll migrate to the libc version. (well if they do it in production, not just testing)

What's the deal with PathBuf::from("/")?

@malinoskj2
Copy link
Author

Cool if libc has a fix that makes sense. I hadn't realized they changed the struct for 12. Looks like this breaks 11 then so probably just close this and use theirs.

For #60 I was getting similar output to his debugs with 88 in the fields (although no subtract with underflow err). statsfs() is failing so most fields are just zeroed out, including f_files and f_ffree. Could cause his error if some values are missing.

After changing to 1024 the fields (including f_files/f_free) actually have values and things seem to be working as you would expect so #60 maybe won't be an issue once the freebsd12 struct is in.

What's the deal with PathBuf::from("/")?

This might be its own issue actually. I thought it was just the Rust's tests being weird with memory. I've had issues in the past where I had to allocate stuff in tests before passing into a function where I would not have had to otherwise.

Looking at this again, I can allocate a PathBuf then pass it into mount_at() either as ref or move and it works. If I try to do a string literal I'm getting:

thread 'main' panicked at 'failed to mount at: Custom { kind: Other, error: StringError("statfs() failed") }', src/libcore/result.rs:997:5

That's both when running the tests and just using the crate.

@valpackett
Copy link
Owner

Yeah, I really should've used a versioned symbol for statfs to ensure we're getting this struct. I'll do that now.

@valpackett valpackett closed this Jun 8, 2019
@valpackett
Copy link
Owner

Fixed now by using versioned symbols

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

Successfully merging this pull request may close these issues.

2 participants