claudetools/clients/valleywide/session-logs/2026-05-16-source-code-recovery-from-backup-drives.md

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/:

# 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