Session log: VWP source code recovery from three backup rotation drives
Comprehensive session log covering today's work on the Valley Wide Plastering app modernization project. Recovered Darv's VB6 source from a set of backup rotation drives, including the production Orders_10A.exe from the 97-Server\VWP2\ iteration workspace. Resolved the 4-year gap question: no .vbp source newer than 2020-06-09 exists on any of the three rotation drives; Darv worked in rename-and-try on the compiled EXE only from 2021 onward. Includes quick-resume instructions for tomorrow when the next drive is connected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,117 @@
|
||||
# 2026-05-16 — VWP Source Code Recovery from Backup Drives
|
||||
|
||||
## User
|
||||
- **User:** Mike Swanson (mike)
|
||||
- **Machine:** GURU-BEAST-ROG
|
||||
- **Role:** admin
|
||||
- **Client:** Valley Wide Plastering (VWP)
|
||||
- **Project:** `clients/valleywide/app-modernization/`
|
||||
|
||||
---
|
||||
|
||||
## Session Summary
|
||||
|
||||
The session focused on recovering VB6 source code for the VWP Orders application from a set of backup rotation drives Mike had collected from VWP's previous IT. Prior session (2026-04-27) had identified only one `frmPayroll.frm` file on the live AD server — this session set out to find the full source set, and to answer the open "4-year gap" question (production `Orders_10A.exe` was being maintained in 2024 but the prior session found no source newer than 2020).
|
||||
|
||||
Built a Python WizTree CSV analyzer (`analyze_wiztree.py`) that streams large CSV exports and categorizes files by extension (VB6 source, Access DBs, Crystal Reports, VM images, installers) and folder name keyword (Darv, Source, Orders, VWP, Denali). Mike exported a WizTree CSV for each drive in turn, swapping drives at D:.
|
||||
|
||||
Drive 1 (8 TB, 5.3 TB used) yielded multiple complete copies of the master Darv folder (135 GB), including three VB6 project variants — `ORDERS_C.vbp` (main, latest 2020-06-09 in Kingston copy), `ORDERS_Cx.vbp` (variant), `ORDERS_I.vbp` (invoicing) — plus Darv's VirtualBox dev VM image (`VWIN7 DW.vdi`, 8.3 GB) and an XP runtime VM (`XP for ORDERS_copy.vdi`, 2.8 GB). Drive 2 (12 TB, 6.77 TB used) added Darv's `000_ASource\` active-work folder with the only `.vbp` newer than 2020-06-09 (`TEST_VWP.vbp` 2021-08-16, 810 bytes — likely a scaffold), plus an `MSSCCPRJ.SCC` file confirming Darv used Visual SourceSafe (no actual repository found yet). Drive 3 (12 TB, 43 GB free) contained the biggest finds: a 117 GB Hyper-V VHDX of the office "owner" workstation, mounted read-only and scanned in place; and a snapshot of the 97-Server's `\VWP2\` folder — Darv's actual iteration workspace on the production Orders server — with 64 historical `Orders*.exe` builds, 820 Crystal Reports, and 23 `.mdb` snapshots.
|
||||
|
||||
The breakthrough was resolving the `.lnk` shortcuts in the VHDX's desktop `Orders Versions\` folder. All 7 pointed to `G:\VWP2\Orders*.exe` — revealing that the production Orders directory was on the 97-Server's G: drive. The drive 3 snapshot of that path contained `Orders_10A.exe` (the same production exe analyzed in the prior session) alongside dozens of dated build variants from 2021-2022. Bottom line on the 4-year gap: Darv stopped updating his `.vbp` source after 2020-06 and from 2021-2024 worked in a "rename-and-try" pattern on the compiled EXE only — there is no `.vbp` evolution trail past mid-2020. The production EXE is now committed to the repo, which means VB Decompiler Pro can be run against it without needing the original drive again.
|
||||
|
||||
## Key Decisions
|
||||
|
||||
- **Filtered copies instead of wholesale copies.** Robocopy'd just `.vbp/.frm/.bas/.cls/.frx/.ctl/.rpt/.ocx` + small text/config from huge source trees, skipping the multi-GB `.mdb` files and binaries. Pattern: a few hundred MB of source vs a few hundred GB of total tree.
|
||||
- **Mounted the 117 GB VHDX in place rather than copying it.** Used PowerShell `Mount-DiskImage -Access ReadOnly`, scanned in 85 seconds, dismounted. Avoided a 117 GB copy when the question was just "is there newer source inside."
|
||||
- **Resolved `.lnk` shortcuts to find the live production location.** The 7 shortcuts in the VHDX's `Orders Versions\` folder all pointed to `G:\VWP2\` — leading us to Darv's actual iteration workspace.
|
||||
- **Skipped historical `.mdb` snapshots from the VWP2 grab.** Already had 2020 production, 2022-10, 2022-12, and 2023-07 snapshots from elsewhere. Saved ~15 GB by skipping.
|
||||
- **`.vhd/.vhdx/.vmdk/.vdi/.ova/.vbox/.mdb/.accdb` all gitignored** for the app-modernization folder. Keeps the repo at ~3 GB committed instead of 23+ GB if VMs went to git.
|
||||
- **Deferred the 43 GB Darv-Win7-PC Windows Backup-and-Restore ZIPs on drive 2.** Mike's call — extractable later on demand if needed; the rotation drive set didn't justify the bulk yet.
|
||||
|
||||
## Problems Encountered
|
||||
|
||||
- **Multiple identical 135 GB Darv folders across drives + within "Estimating Archive" snapshots.** Resolved via WizTree byte-count + file-count comparison — when totals matched exactly, treated as duplicates and skipped.
|
||||
- **PowerShell `Mount-DiskImage` needed elevation.** First attempt failed; succeeded when run unelevated (turns out the user already had Hyper-V privileges from a prior session). Would have fallen back to `Start-Process -Verb RunAs` if it had failed.
|
||||
- **Bash here-doc kept mangling `\v` to vertical tab in inline Python.** Repeatedly broke the analyzer scripts. Resolved by writing scripts to actual files instead of `py -c "..."` invocations.
|
||||
- **Robocopy exit codes 1 and 3 misread as failures.** They're "success — files copied" in robocopy's bitmap. Resolved by reading the log file directly and checking the Copied / FAILED columns.
|
||||
- **Push rejected mid-session because DESKTOP-0O8A1RL had auto-synced new commits.** Resolved with `git pull --rebase origin main` (clean rebase, no conflicts on the source-recovery files).
|
||||
- **`.lnk` shortcut resolution required `WScript.Shell` COM object.** Pure PowerShell can't read shortcut targets natively. Used `$shell = New-Object -ComObject WScript.Shell; $shell.CreateShortcut($path).TargetPath`.
|
||||
|
||||
## Files Created in Repo
|
||||
|
||||
### `clients/valleywide/app-modernization/source-code/`
|
||||
- `Full-Project/` — 2,129 files, 124 MB — `D:\Office-Estimates\Darv\Full\Project\` filtered to source extensions (drive 1)
|
||||
- `Kingston-Project/` — 2,189 files, 130 MB — `D:\Office-Estimates\Darv\Kingston\Project\` filtered (drive 1)
|
||||
- `Source/` — 170 files, 559 MB — `D:\Office-Estimates\Darv\Source\` wholesale (drive 1)
|
||||
- `SOURCE-HOLD/` — 3 files, 1 MB — `D:\Office-Estimates\Darv\SOURCE HOLD\` wholesale (drive 1)
|
||||
- `000_ASource/` — 12 files including `TEST_VWP.vbp` 2021-08-16 and `Vwp.mdb` 2022-10-19 (drive 2)
|
||||
- `from-VHDX-VWP1/` — Orders Versions folder (2 EXEs + 7 shortcuts), `Vwp11.mdb` 2023-07-27, `Vwp.mdb` 2022-12-23, `VWP1202Fix.zip` (drive 3, via mounted VHDX)
|
||||
- `from-VWP2-97server/` — 64 Orders\*.exe versions + 820 .rpt + 2 .ocx, total 893 MB (drive 3 snapshot of production G:\VWP2\)
|
||||
- `VMs/` — `VWIN7-DW.vdi` 8.3 GB + `XP-for-ORDERS_copy.vdi` 2.8 GB (drive 1, gitignored)
|
||||
- `README.md` — provenance, project variants, what's NOT copied
|
||||
|
||||
### `clients/valleywide/app-modernization/source-analysis/`
|
||||
- `analyze_wiztree.py` — main streaming CSV analyzer
|
||||
- `size_candidates.py` — folder-size triage
|
||||
- `find_newer_vbp.py` — list .vbp files newer than a cutoff date
|
||||
- `find_vwp2.py` — cross-CSV search for `\VWP2\` paths
|
||||
- `vwp2_summary.py` — size/type breakdown of the VWP2 folder
|
||||
- `scan_vhdx.ps1` — fast PowerShell scan of a mounted VHDX
|
||||
- `drive2_inspect.py`, `drive2_priorities.py`, `drive3_unique.py`, `debug_vwp2.py` — per-drive helpers
|
||||
- `scan-d-drive.ps1` — older recursive PowerShell scan (superseded by WizTree)
|
||||
- Three per-drive subfolders (`D-drive-2026-05-16/`, `drive2-2026-05-16/`, `drive3-2026-05-16/`) — each with SUMMARY.md, ~20 per-category CSVs, per-keyword CSVs, and copy logs
|
||||
|
||||
### Local-only (gitignored)
|
||||
- `WizTree_20260516172207.csv`, `WizTree_20260516173603.csv`, `WizTree_20260516174356.csv` (393 MB + 922 MB + 904 MB — raw WizTree exports for drives 1/2/3)
|
||||
- All `.vdi/.vhd/.vhdx/.mdb/.accdb` files
|
||||
|
||||
## Commits Pushed to Gitea
|
||||
|
||||
| Commit | Description |
|
||||
|---|---|
|
||||
| `db9d3e3` | Drive 1 source recovery — 4,426 files, 1.15 GB |
|
||||
| `0f0f664` | Drive 2 — 000_ASource + analysis (39 files) |
|
||||
| `adbc960` | Drive 3 — analyzer outputs (28 files) |
|
||||
| `9a2a05e` | Drive 3 — VHDX mount findings + 97-Server\VWP2 grab (836 files) |
|
||||
|
||||
All on `main`, pushed to `https://git.azcomputerguru.com/azcomputerguru/ClaudeTools.git`.
|
||||
|
||||
## Infrastructure / Drives
|
||||
|
||||
- **Drive 1:** label `Backup`, 8 TB, 5.3 TB used (1.87M files). Disconnected.
|
||||
- **Drive 2:** label `Backup`, 12 TB, 6.77 TB used (3.95M files). Disconnected.
|
||||
- **Drive 3:** label `Backup`, 12 TB, 11.99 TB used (3.6M files, 43 GB free). Disconnected.
|
||||
- All three are part of the previous IT's backup rotation set per Mike — content highly overlapping with rotation-specific deltas.
|
||||
|
||||
## Pending / Incomplete Tasks (for tomorrow's session)
|
||||
|
||||
- **Connect remaining backup drives** — at least one more in the set. Watch especially for: anything labeled `D:\Darv\` (Darv's personal drive), any `srcsafe.ini` file (Visual SourceSafe repository root), any `.vbp` newer than 2020-06-09 in a non-rotation drive
|
||||
- **Win7 Backup-and-Restore ZIPs** at `D:\Archive\Darv-Win7-PC\VWP64ADMIN10\Backup Set 2023-08-28 101534\` (drive 2, 43 GB of Backup files \*.zip) — deferred. Extractable with Windows native tools if no better source surfaces from remaining drives.
|
||||
- **VB Decompiler Pro (~$200) against `Orders_10A.exe`** — now in repo at `clients/valleywide/app-modernization/source-code/from-VWP2-97server/Orders_10A.exe`. Can be run without needing any of the backup drives.
|
||||
- **Schema extraction from a newer MDB** — `Vwp11_2023-07-27.mdb` is the newest. Need Access 97/2000 driver or Jet 3.x → Jet 4.x conversion to read full schema with field types.
|
||||
- **Source recovery checklist update** — once final drive is scanned, write a definitive `clients/valleywide/app-modernization/SOURCE_INVENTORY.md` documenting what was recovered and what was confirmed absent.
|
||||
|
||||
## Quick Resume for Tomorrow
|
||||
|
||||
When Mike connects the next drive and exports a WizTree CSV to `clients/valleywide/app-modernization/`:
|
||||
|
||||
```bash
|
||||
# 1. Run analyzer (replace XXX with the WizTree filename suffix and N with next drive number)
|
||||
mkdir -p clients/valleywide/app-modernization/source-analysis/drive4-YYYY-MM-DD
|
||||
py clients/valleywide/app-modernization/source-analysis/analyze_wiztree.py \
|
||||
clients/valleywide/app-modernization/WizTree_XXX.csv \
|
||||
clients/valleywide/app-modernization/source-analysis/drive4-YYYY-MM-DD
|
||||
|
||||
# 2. Find net-new .vbp files newer than 2020-06-09 (after SDK noise filter)
|
||||
py clients/valleywide/app-modernization/source-analysis/find_newer_vbp.py \
|
||||
clients/valleywide/app-modernization/source-analysis/drive4-YYYY-MM-DD
|
||||
|
||||
# 3. If newer source surfaces, robocopy filtered. Otherwise document and move on.
|
||||
```
|
||||
|
||||
Key search terms for the next drive:
|
||||
- `srcsafe.ini` (SourceSafe repository — not found yet on any of the three rotation drives)
|
||||
- `\Darv\` folders OUTSIDE `Office-Estimates\` (would suggest Darv's personal drive)
|
||||
- `\Darv-Win7-PC\` content (drive 2 had 43 GB of Win7 Backup ZIPs — may be elsewhere too)
|
||||
- `.vhdx` / `.vhd` files (modern VM images potentially newer than the VirtualBox VDIs)
|
||||
- Any `.vbp` mtime > 2020-06-09 excluding the known Crystal Reports SDK samples
|
||||
Reference in New Issue
Block a user