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

Code 87 when attempting to write files #92

Closed
asevans48 opened this issue Jun 10, 2020 · 1 comment
Closed

Code 87 when attempting to write files #92

asevans48 opened this issue Jun 10, 2020 · 1 comment

Comments

@asevans48
Copy link

asevans48 commented Jun 10, 2020

Issue

The program can read files but switching to a mutable map in memmap-rs or memmap2 on Windows breaks due to an inappropriate call to Windows. The resulting error is a code 87 incorrect parameter error. I would love some guidance on what the actual issue is or a patch as I am actively trying to build a cache system after all other options appear to have moved to a NoSQL database due to popularity. My goal is to achieve a near-real-time tracking system for streaming ETL. Memory mapping allows me to avoid constantly loading files from memory in a SQL-lite memory-mapped style approach to storage.

Action

Switch from an immutable memory map to a mutable map.

Code in memmap/memmap2/memmap-rs

let mut file2 = File::open("E:\testfiles\mmap\test.mmap").unwrap();
let map = unsafe{MmapOptions::new().map(&file2).unwrap()};
let mut mut_map = map.make_mut().unwrap();

Expected Result

The retrieval of a writable/mutable memory mapping.

Actual Result

The action on line 3 fails with an apparent winapi issue:

thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 87, kind: Other, message: "The parameter is incorrect." }', src\main.rs:35:23

Stack Trace

thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 87, kind: Other, message: "The parameter is incorrect." }', src\main.rs:35:23
stack backtrace:
0: backtrace::backtrace::trace_unsynchronized
at C:\Users\VssAdministrator.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.46\src\backtrace\mod.rs:66
1: std::sys_common::backtrace::_print_fmt
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\sys_common\backtrace.rs:78
2: std::sys_common::backtrace::_print::{{impl}}::fmt
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\sys_common\backtrace.rs:59
3: core::fmt::write
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libcore\fmt\mod.rs:1076
4: std::io::Write::write_fmtstd::sys::windows::stdio::Stderr
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\io\mod.rs:1537
5: std::sys_common::backtrace::_print
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\sys_common\backtrace.rs:62
6: std::sys_common::backtrace::print
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\sys_common\backtrace.rs:49
7: std::panicking::default_hook::{{closure}}
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panicking.rs:198
8: std::panicking::default_hook
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panicking.rs:218
9: std::panicking::rust_panic_with_hook
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panicking.rs:486
10: std::panicking::begin_panic_handler
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panicking.rs:388
11: core::panicking::panic_fmt
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libcore\panicking.rs:101
12: core::option::expect_none_failed
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libcore\option.rs:1272
13: core::result::Result<memmap::MmapMut, std::io::error::Error>::unwrapmemmap::MmapMut,std::io::error::Error
at C:\Users\aseva.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libcore\result.rs:1005
14: test_other_stuff::main
at .\src\main.rs:35
15: std::rt::lang_start::{{closure}}<()>
at C:\Users\aseva.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\rt.rs:67
16: std::rt::lang_start_internal::{{closure}}
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\rt.rs:52
17: std::panicking::try::do_call
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panicking.rs:297
18: std::panicking::try
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panicking.rs:274
19: std::panic::catch_unwind
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\panic.rs:394
20: std::rt::lang_start_internal
at /rustc/fe10f1a49f5ca46e57261b95f46f519523f418fe/src\libstd\rt.rs:51
21: std::rt::lang_start<()>
at C:\Users\aseva.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\rt.rs:67
22: main
23: invoke_main
at d:\agent_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
24: __scrt_common_main_seh
at d:\agent_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
25: BaseThreadInitThunk
26: RtlUserThreadStart
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
error: process didn't exit successfully: target\debug\test-other-stuff.exe (exit code: 101)

@asevans48
Copy link
Author

I found the problem. It was my firewall. Sorry guys. Had me hammering at file permissions and all kinds of things.

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

No branches or pull requests

1 participant