What do you think about ?

let io_blksize: Option<usize> = matches.get_one::<String>(OPT_IO_BLKSIZE).map(|s| {
    parse_size_u64(s)
        .ok()
        .and_then(|n| {
            let n = n.try_into().map_err(|_| SettingsError::InvalidIOBlockSize(s.to_string()))?;
            if n > OPT_IO_BLKSIZE_MAX {
                Err(SettingsError::InvalidIOBlockSize(s.to_string()))
            } else {
                Ok(n)
            }
        })
}).transpose()?;

in this case it would "eat" possible error returned by parse_size_u64(), so it cannot be bubbled up to from()->Result. Also, since ok() converts it to Option and the and_then() expects an option to be returned from the closure, it is not straitforward to return the SettingsError in either places within the closure inside closure - i.e. doing return Err(SettingsError::InvalidIOBlockSize(s.to_string())) or Some(Err(SettingsError::InvalidIOBlockSize(s.to_string()))) would not work : as return is not for from()->Result function but closure, and wrapping in Some() to satisfy and_then() signature we will end up with Option<Option<Result<>>> as a retuning value from closure from map() instead of Option<Result<>> ... could unwrap(), but then still missing/eating error from parse_size_u64() ...
I could be missing something though

please ignore my comment then :(

what about an early exit ?

same:

same, early return

Here's an example from GNU:

❯ split ---
split: option '---io-blksize' requires an argument
Try 'split --help' for more information.
❯ split ---io-bl
split: option '---io-blksize' requires an argument
Try 'split --help' for more information.

This is not a separate option, but one of those things where a long argument can be shortened to the first few letters if its unambiguous. clap supports this too and I think it's turned on (it's infer_long_args(true)) so do we need this?

yep, looks like it is the case. will remove

Why this change? The original code makes sense to me. If we need it to fit in a usize why wouldn't we make it a usize?

it made sense for the original code because num_chunks was later used in method calls that require usize like writers.iter_mut().take(num_chunks - 1), and there was a test to test for that error - looks like only for code coverage %. I left it in to keep the test, but looking at it more closely - it does not need to be usize, so I will remove it along with the test that checked for it.

This feels inherently brittle and I'm wondering whether there's a better way to do it. For example, we could have links to all of these filesystems and that should still work. Based on the syscalls they make, I don't think GNU has exceptions like, though I'm not entirely sure what they are doing instead.

I think they might just try to get the length first and try this other method if that returns 0? I'm not sure.

in GNU they first go straight to reading it into a buffer and then compare that to what metadata/filesystem is reporting + do seek on the file if those disagree (as well as trying to copy things arround into temp file/buffer, etc) and some other edge cases. I tried to avoid reading file into a buffer first for everything, but could re-implement to closer follow GNU approach

I think doing what GNU does is the right call! Nice investigative work! (As a precaution: remember not to look at the GNU source code)

should be ready to go

Would this work?

for i in 1.. {
    ...
}