feat(flr): windows paths, recovery-site gate, stable partition reads #4

2026-09-21T14:05:22-04:00

claude commented

2026-09-21 14:05:22 -04:00

Three fixes from actually measuring FLR against a Windows guest (ad1, VPG local) rather than only the Linux one. All verified live; nothing here ships on inference.

1. Gate FLR to locally replicated VPGs

FLR is performed at the VPG's recovery site — that's where the mount is created. A VPG replicating to a cloud ZCA must be recovered through that ZCA's API, not the protected ZVM's.

Supporting that properly means holding credentials for every ZVM/ZCA in a customer estate and routing the call to the right one. That's a real design decision, not something to smuggle in. Until then zerto_recover_file refuses a VPG where protected site != recovery site and names the site that owns the operation:

{
  "ok": false,
  "not_local_replication": true,
  "vpg_name": "CMH-AWS-4",
  "recovery_site": "aws-zca",
  "message": "FLR for VPG 'CMH-AWS-4' lives at its recovery site (aws-zca), not at this ZVM. ..."
}

Previously this would proceed and fail later as a confusing path or mount error.

2. Windows paths are not symmetrical with Linux

	guest path	FLR path
Linux	`/home/j/app.yaml`	`Volume2-Ext4%2fhome%2fj%2fapp.yaml`
Windows	`C:\Users\j\f.conf`	`C%3a%2fUsers%2fj%2ff.conf`

On Windows the drive letter is the partition name, so the guest path already carries it. The old code prepended unconditionally and built C:/C:/Users/j — could never match. resolve_flr_path now detects when the path already starts with the partition.

Two related corrections:

It returns the raw path exactly as browse reported it. Download accepts raw and decoded, and returning raw avoids re-encoding by hand.
Decoding is now unquote_plus. Browse form-encodes a space as + (Program+Files), and plain unquote left it, so a basename compare against Program Files never matched. Matching tries exact first, then case-insensitive — Windows is case-insensitive, Linux is not.

3. Wait for partition enumeration to settle

A session reports mounted before the ZVM has finished identifying volumes, and browsing in that window returns a partial, mis-labelled list. The same Windows VM enumerated as Volume4-Unknown with no C: drive, then moments later as a browsable C%3a holding the whole filesystem — three mounts gave three different partition lists.

Acting on the early list makes a restorable NTFS disk look permanently unrestorable. I hit exactly that and wrongly concluded C: was unsupported. wait_partitions_stable now polls until the list stops changing.

Verified against ZVM 10.x

CMH-AWS-4 (recovery aws-zca) refused, naming the site
C:\ad1.keytab recovered — 58 bytes
C:\Program Files\internet explorer\sqmapi.dll recovered — 47512 bytes; drive letter, two spaces, nested dirs, the exact case that was broken
Linux /home/justin/app-config.yaml still recovers — 158 bytes (regression check)
every session unmounted, unmount.ok: true

Also drops a duplicate get_vpg that silently shadowed the existing one (caught by ruff F811).

pytest: 32 passed (7 new, covering the Windows drive-letter case, +-encoded spaces, the settling partition list, and both gate outcomes). ruff check clean on changed files.

Deliberately not included, as discussed: the can_tag cloud-protected false positive, and Windows entries for the mutating catalog. Both are separate calls.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

Three fixes from actually measuring FLR against a **Windows** guest (`ad1`, VPG `local`) rather than only the Linux one. All verified live; nothing here ships on inference. ## 1. Gate FLR to locally replicated VPGs FLR is performed at the VPG's **recovery** site — that's where the mount is created. A VPG replicating to a cloud ZCA must be recovered through *that ZCA's* API, not the protected ZVM's. Supporting that properly means holding credentials for every ZVM/ZCA in a customer estate and routing the call to the right one. That's a real design decision, not something to smuggle in. Until then `zerto_recover_file` refuses a VPG where protected site != recovery site and **names the site that owns the operation**: ```json { "ok": false, "not_local_replication": true, "vpg_name": "CMH-AWS-4", "recovery_site": "aws-zca", "message": "FLR for VPG 'CMH-AWS-4' lives at its recovery site (aws-zca), not at this ZVM. ..." } ``` Previously this would proceed and fail later as a confusing path or mount error. ## 2. Windows paths are not symmetrical with Linux | | guest path | FLR path | |---|---|---| | Linux | `/home/j/app.yaml` | `Volume2-Ext4%2fhome%2fj%2fapp.yaml` | | Windows | `C:\Users\j\f.conf` | `C%3a%2fUsers%2fj%2ff.conf` | On Windows the **drive letter is the partition name**, so the guest path already carries it. The old code prepended unconditionally and built `C:/C:/Users/j` — could never match. `resolve_flr_path` now detects when the path already starts with the partition. Two related corrections: - It returns the **raw** path exactly as browse reported it. Download accepts raw *and* decoded, and returning raw avoids re-encoding by hand. - Decoding is now `unquote_plus`. Browse form-encodes a space as `+` (`Program+Files`), and plain `unquote` left it, so a basename compare against `Program Files` never matched. Matching tries exact first, then case-insensitive — Windows is case-insensitive, Linux is not. ## 3. Wait for partition enumeration to settle A session reports `mounted` before the ZVM has finished identifying volumes, and browsing in that window returns a partial, **mis-labelled** list. The same Windows VM enumerated as `Volume4-Unknown` with no C: drive, then moments later as a browsable `C%3a` holding the whole filesystem — three mounts gave three different partition lists. Acting on the early list makes a restorable NTFS disk look permanently unrestorable. I hit exactly that and wrongly concluded C: was unsupported. `wait_partitions_stable` now polls until the list stops changing. ## Verified against ZVM 10.x - `CMH-AWS-4` (recovery `aws-zca`) refused, naming the site - `C:\ad1.keytab` recovered — 58 bytes - `C:\Program Files\internet explorer\sqmapi.dll` recovered — **47512 bytes**; drive letter, two spaces, nested dirs, the exact case that was broken - Linux `/home/justin/app-config.yaml` still recovers — 158 bytes (regression check) - every session unmounted, `unmount.ok: true` Also drops a duplicate `get_vpg` that silently shadowed the existing one (caught by ruff F811). `pytest`: 32 passed (7 new, covering the Windows drive-letter case, `+`-encoded spaces, the settling partition list, and both gate outcomes). `ruff check` clean on changed files. Deliberately **not** included, as discussed: the `can_tag` cloud-protected false positive, and Windows entries for the mutating catalog. Both are separate calls. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

claude added 1 commit 2026-09-21 14:05:22 -04:00

feat(flr): windows paths, recovery-site gate, stable partition reads 6d87fae60d

Three fixes from measuring FLR against a Windows guest (ad1, VPG 'local')
instead of only the Linux one.

1. Gate FLR to locally replicated VPGs.

   FLR is performed at the VPG's RECOVERY site, because that is where the
   mount is created. A VPG replicating to a cloud ZCA has to be recovered
   through that ZCA's API, not the protected ZVM's. Supporting that
   properly means holding credentials for every ZVM/ZCA in an estate and
   routing the call, which is a real design decision, not something to
   smuggle in. Until then zerto_recover_file refuses a VPG whose
   protected site != recovery site and names the site that owns the
   operation, instead of failing later as a confusing path or mount error.

2. Windows paths are not symmetrical with Linux.

   Linux   /home/j/app.yaml  -> Volume2-Ext4%2fhome%2fj%2fapp.yaml
   Windows C:\Users\j\f.conf -> C%3a%2fUsers%2fj%2ff.conf

   On Windows the drive letter IS the partition name, so the guest path
   already carries it. The old code prepended unconditionally and built
   'C:/C:/Users/j', which could never match. resolve_flr_path now detects
   that the path already starts with the partition.

   It also returns the raw path exactly as browse reported it. Download
   accepts the raw and the decoded form, and returning raw avoids
   re-encoding by hand. Decoding is now unquote_plus, not unquote: browse
   form-encodes a space as '+' ("Program+Files"), so a basename compare
   against "Program Files" never matched. Matching tries exact first and
   only then case-insensitively, since Windows is case-insensitive and
   Linux is not.

3. Wait for partition enumeration to settle.

   A session reports mounted before the ZVM has finished identifying
   volumes, and browsing in that window returns a partial, MIS-LABELLED
   list. The same Windows VM enumerated as 'Volume4-Unknown' with no C:
   drive, then moments later as a browsable 'C%3a' holding the whole
   filesystem. Acting on the early list makes a restorable NTFS disk look
   permanently unrestorable. wait_partitions_stable polls until the list
   stops changing.

Verified against ZVM 10.x:

- CMH-AWS-4 (recovery aws-zca) refused, naming aws-zca
- C:\ad1.keytab recovered, 58 bytes
- C:\Program Files\internet explorer\sqmapi.dll recovered, 47512 bytes --
  drive letter, two spaces, nested dirs, the exact case that was broken
- Linux /home/justin/app-config.yaml still recovers, 158 bytes
- every session unmounted, unmount.ok true

Also drops a duplicate get_vpg that shadowed the existing one (F811).

pytest 32 passed (7 new).

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

claude merged commit 90768f17e1 into main

2026-09-21 14:11:09 -04:00

claude deleted branch feat/flr-windows-and-local-gate

2026-09-21 14:11:10 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: justin/zerto-ai-rewind#4