fix(fuzz): fall back to fs operator so fuzz targets produce real coverage

[tonghuaroot]

Which issue does this PR close?

Closes #7722.

Rationale for this change

All OSS-Fuzz targets exit immediately when OPENDAL_TEST is unset because init_test_service() returns None. OSS-Fuzz never sets this variable, so coverage has been stuck at 0.26% (harness startup only) since integration.

What changes are included in this PR?

• fuzz_reader.rs / fuzz_writer.rs: replace the if let Some(op) early-return with a LazyLock<Operator> that falls back to a local Fs operator in a temp directory when no test service is configured.
• fuzz/Cargo.toml: enable services-fs feature so the fallback compiles.
• New fuzz_path.rs target: feeds arbitrary strings as paths through write/stat/list/copy/rename/delete — already found a real bug (fix(services/fs): preserve backslash in filenames on Unix during list #7721) within 2 minutes of running.

Are there any user-facing changes?

No. Changes are limited to the core/fuzz/ directory which is only used by cargo fuzz and OSS-Fuzz.

AI Usage Statement

Claude was used for assistance with fuzz target development.

[erickguan]

Good find! Do we need a fallback since we could always exit 1 and warn the user in fuzzer test? Because a test failure will force us to check CI status.

[tonghuaroot]

Thanks @erickguan! Good question. The fallback is deliberately scoped to the unconfigured case only:

• init_test_service() returns Ok(None) when OPENDAL_TEST is unset, Ok(Some(op)) when a service is selected and inits, and Err(..) when a selected service fails to init.
• So init_test_service().expect("operator init must succeed") still panics loudly if someone explicitly sets e.g. OPENDAL_TEST=s3 and it fails to init — a genuine misconfiguration does fail the run and shows up in CI, exactly as you want. The fs fallback only kicks in for the Ok(None) (nothing selected) case.

The reason we fall back instead of exit 1 in that unconfigured case is OSS-Fuzz: it runs these binaries continuously with no OPENDAL_TEST env set (that's the root cause of the zero coverage in #7722). If the target exited 1 / panicked when unconfigured, OSS-Fuzz would just record every run as an immediate crash and we'd still get no useful coverage — the same dead state we're fixing, only louder. Falling back to fs (which needs no external setup beyond a temp dir, and exercises OpenDAL's real path-handling code) gives the fuzzer something concrete to drive, while local/CI runs can still target any specific service via OPENDAL_TEST.

Happy to switch the unconfigured default to memory instead if you'd prefer to avoid filesystem side effects — just let me know which you'd like.

[tonghuaroot]

Added a log::warn! on the unconfigured fallback per your suggestion (pushed in 1468565) so it's visible in logs. PTAL!

[erickguan]

Thanks for the context. I understand the problem much better.

If the target exited 1 / panicked when unconfigured, OSS-Fuzz would just record every run as an immediate crash and we'd still get no useful coverage — the same dead state we're fixing, only louder

Indeed true. Having a silent fallback to fs works to bring back fuzz coverage. This would be a good fix.
Now considering a maintenance perspective, if Ok(None) panics, any maintainers would be able to tell something requires for a fix. It might be stringent to understand fuzz setup but that would help someone else to jump in.
Nevertheless, I would be happy to see we are getting fuzz coverage. So your call.

[tonghuaroot]

For reviewers' context: this also unblocks the OSS-Fuzz side — google/oss-fuzz#15648 updates the build to pull these four targets and fixes the moved repo URL, and is just waiting on this to land. CI here is green; happy to address any feedback. Addresses #7722.

[erickguan]

See inline comment. I would be happier to see a panic test without env. Also happy to see the ball gets rolling.

[erickguan]

Also thanks for taking care of oss-fuzz!