fix!: fallback to the root mountpoint when no matching mountpoints found

[kricsleo]

resolves #336

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.00%. Comparing base (70310f9) to head (3e2f48d).
Report is 12 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #616   +/-   ##
=======================================
  Coverage   59.99%   60.00%           
=======================================
  Files          42       42           
  Lines        3657     3735   +78     
  Branches      590      602   +12     
=======================================
+ Hits         2194     2241   +47     
- Misses       1460     1491   +31     
  Partials        3        3           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pi0]

Thanks, this is a valid fix however since risky (some usage might have been depending on faulty behavior and this can cause data loss) we should do it as a major version.

[ToBinio]

Hi,
I just did a small deep dive into the clear function because of #642 (comment) and #638 (comment)

Is it really the best idea to delete the whole DB if I enter a too precise prefix? Isn't that kinda backwards?
I also don't think this solves #336 since the behaviors still differ... getKeys returns the expected subset and clear nukes the whole storage

---

unstorage/src/storage.ts

Line 387 in 2519250

getMounts(base, false).map(async (m) => {

I would suggest having getMounts(base, true) in clear and letting the drivers handle only deleting a subset of data.
Some drivers e.g. redis would already handle that