Windows probably is not where most people deploy Qdrant, so I see this as a small edge case rather than an urgent production issue. I opened the PR because the CLI already accepts PATH:NAME, and valid Windows drive-letter paths currently do not fit that parser. I think either accepting or declining this PR would be reasonable, or it can at least serve as an issue to discuss this edge case.

All Submissions:

⚠️ PRs must target the dev branch. If your PR targets master, please change the base branch to dev before requesting a review.

• My PR targets the dev branch (not master) and my branch was created from dev.
• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you successfully ran tests with your changes locally?

What changed

What Problem This Solves

CLI snapshot recovery accepts mappings in the documented <snapshot_file_path>:<target_collection_name> shape. That convention is straightforward for POSIX paths such as /tmp/collection.snapshot:test_collection and for relative paths such as collection.snapshot:test_collection, because the only colon is the separator between the snapshot path and the target collection name.

Windows absolute paths are different. A valid Windows path can contain a drive-letter prefix, so a normal mapping can look like this:

C:\tmp\collection.snapshot:test_collection

In that string, the first colon belongs to the path itself (C:), while the final colon is the actual mapping separator before test_collection.

Before this change, recover_snapshots() used split(':'), which treats every colon as a separator. For the Windows example above, the parser did not see one path and one collection name. It saw three pieces instead:

C
\tmp\collection.snapshot
test_collection

That means C was incorrectly treated as the snapshot path, \tmp\collection.snapshot was incorrectly treated as the collection name, and test_collection became an unexpected third part. Because of that third part, the parser rejected the mapping with Too many parts in snapshot mapping before snapshot recovery could start.

So the issue is not that the Windows path is invalid. The path is valid, but the CLI mapping parser consumes the drive-letter colon as if it were part of the PATH:NAME protocol. This makes a valid Windows snapshot path impossible to express through the documented CLI mapping format.

Changes

This PR moves snapshot mapping parsing into a small internal SnapshotMapping type and parses CLI mappings from the final colon. Earlier colons stay with the snapshot path, so Windows drive-letter paths keep their drive prefix while the documented PATH:NAME shape remains unchanged.

It also avoids the same string-protocol round trip in full-storage snapshot recovery. recover_full_snapshot() already reads structured snapshot configuration, so it now builds SnapshotMapping values directly instead of formatting unpacked snapshot paths back into PATH:NAME strings and parsing them again.

Evidence

The focused tests cover the old failing shape and the nearby parser boundaries:

C:\tmp\collection.snapshot:test_collection

Before this change, that mapping could be split into C, \tmp\collection.snapshot, and test_collection, which hit Too many parts in snapshot mapping. After this change, the parser returns:

snapshot path: C:\tmp\collection.snapshot
collection:    test_collection

The test suite also covers POSIX absolute paths, relative paths, paths with earlier colons, missing separators, empty paths, and empty collection names.

Possible call chain / impact

qdrant --snapshot <PATH:NAME>
  -> recover_collections_from_snapshot_args(...)
  -> recover_snapshots(...)
  -> SnapshotMapping::from_cli_arg(...)
  -> Collection::restore_snapshot(...)

qdrant --storage-snapshot <PATH>
  -> recover_full_snapshot(...)
  -> SnapshotConfig.collections_mapping
  -> SnapshotMapping { snapshot_path, collection_name }
  -> recover_snapshot_mappings(...)

This only changes startup CLI snapshot mapping parsing and the internal full-storage snapshot mapping handoff. It does not change CLI flag names, collection restore behavior after parsing, REST/gRPC snapshot recovery APIs, or snapshot storage formats.

Scope

Affected:

• --snapshot PATH:NAME
• --collection-snapshot PATH:NAME
• internal full-storage snapshot recovery mapping construction

Unchanged:

• CLI flag names and documented PATH:NAME shape
• collection restore behavior after a mapping has been parsed
• REST and gRPC snapshot recovery APIs
• snapshot storage formats

Validation

• cargo +nightly fmt --all --check
• git diff --check
• cargo test -p qdrant snapshot_mapping -- --nocapture

Focused test result:

running 8 tests
test snapshots::tests::snapshot_mapping_accepts_relative_path ... ok
test snapshots::tests::snapshot_mapping_accepts_windows_absolute_path ... ok
test snapshots::tests::snapshot_mapping_accepts_posix_absolute_path ... ok
test snapshots::tests::snapshot_mapping_rejects_empty_collection_name - should panic ... ok
test snapshots::tests::snapshot_mapping_rejects_missing_separator - should panic ... ok
test snapshots::tests::snapshot_mapping_rejects_windows_path_without_collection_name - should panic ... ok
test snapshots::tests::snapshot_mapping_rejects_empty_path - should panic ... ok
test snapshots::tests::snapshot_mapping_splits_on_last_colon ... ok

test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 147 filtered out; finished in 0.00s

AI disclosure

Commit 97dd739c497f200e8be92d198dca9ffa18a7055e was prepared with AI assistance. Initial prompt intent: fix Qdrant CLI snapshot mapping parsing so Windows drive-letter paths are not split at the drive colon.