Skip to content

fix: Migration handles deeply nested Windows project files#1396

Merged
hatayama merged 2 commits into
v3-betafrom
feature/fix-migration-windows
Jun 24, 2026
Merged

fix: Migration handles deeply nested Windows project files#1396
hatayama merged 2 commits into
v3-betafrom
feature/fix-migration-windows

Conversation

@hatayama

@hatayama hatayama commented Jun 24, 2026

Copy link
Copy Markdown
Owner

Summary

  • Migration preview and apply now handle deeply nested Windows project files that exceed legacy path limits.
  • Cached migration plans now invalidate correctly after long-path files change.

User Impact

  • On Windows, running the migration tool could stop with a misleading "Could not find a part of the path" error in projects with very long file paths.
  • The migration flow now reads, writes, and validates those files through extended-length file access so the operation can complete reliably.

Changes

  • Route third-party migration reads, writes, and atomic sidecar operations through Windows extended-length path handling.
  • Apply the same access path to migration plan fingerprint metadata and content hashes.
  • Add Windows-only regression coverage for long-path preview, apply, directory discovery, and stale-cache invalidation.

Verification

  • .\cli\dist\windows-amd64\uloop.exe compile
  • .\cli\dist\windows-amd64\uloop.exe run-tests --test-mode EditMode --filter-type regex --filter-value ".(WindowsDirectoryPathExceedsLegacyLimit|MigrationProjectFingerprint_WhenWindowsPathExceedsLegacyLimit)."
  • .\cli\dist\windows-amd64\uloop.exe run-tests --test-mode EditMode --filter-type regex --filter-value ".ThirdPartyToolMigration."
  • python C:\Users\booql.codex\skills\autoreview\scripts\autoreview --mode branch --base origin/v3-beta
  • git diff --check

Review in cubic

hatayama added 2 commits June 25, 2026 01:05
Route third-party migration reads and writes through extended-length Windows paths so preview and apply do not fail on MAX_PATH-sized project files. Add Windows-only regression coverage for long-path preview and apply flows.
Use the migration long-path file access wrapper for cached plan fingerprint metadata and content hashes so edits to long-path source files invalidate preview plans correctly. Add Windows-only regression coverage for long-path discovery and fingerprint changes.
@coderabbitai

coderabbitai Bot commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Introduces an internal ThirdPartyToolMigrationFileAccess class in ThirdPartyToolMigrationFileWriter.cs that normalizes file paths to Windows extended-length form (\\?\) before delegating to System.IO APIs. Four Windows path-limit constants are added to ThirdPartyToolMigrationFileServiceConstants. All direct System.IO.File.* calls across the migration pipeline (14 files) are replaced with this abstraction. Four Windows-only tests validate the long-path behavior.

Changes

Windows Long-Path File Access Abstraction

Layer / File(s) Summary
Path constants and ThirdPartyToolMigrationFileAccess implementation
Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationFileServiceConstants.cs, Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationFileWriter.cs
Adds WindowsLegacyMaxPathLength, WindowsExtendedLengthPathPrefix, WindowsExtendedLengthUncPathPrefix, and WindowsUncPathPrefix constants. Introduces the internal ThirdPartyToolMigrationFileAccess class with GetFileSystemPath (applies extended-length prefix for paths exceeding 260 chars, with UNC-aware branching) and wrapper methods for all System.IO.File.* operations. ThirdPartyToolMigrationFileWriter.Write and CreateUniqueSidecarPath are updated to use the new abstraction.
Call-site migration to ThirdPartyToolMigrationFileAccess
Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationSourceFileCache.cs, ThirdPartyToolMigrationModels.cs, ThirdPartyToolMigrationPreflightScanner.cs, ThirdPartyToolMigrationTargetScanner.cs, ThirdPartyToolMigrationPlanBuilder.cs, ThirdPartyToolMigrationAssemblyUsageAnalyzer.cs, ThirdPartyToolMigrationFastAssemblyRequirementCollector.cs, ThirdPartyToolMigrationFastSourceTargetDetector.cs, ThirdPartyToolMigrationAsmdefMetaGuidReader.cs, ThirdPartyToolMigrationAsmdefMigrationRequirementResolver.cs, ThirdPartyToolMigrationAssemblyReferenceResolver.cs
Replaces all System.IO.File.ReadAllText, File.Exists, File.OpenRead, File.ReadLines, and FileInfo-based calls with the corresponding ThirdPartyToolMigrationFileAccess static methods. Removes now-unnecessary using System.IO; directives in three files. No control-flow changes.
Windows long-path tests
Assets/Tests/Editor/ThirdPartyToolMigrationFileServiceTests.cs
Adds a using static import for path constants and four [Platform(Include = "Win")] test methods covering: source file cache reading from extended-length paths, ApplyMigrationAsync with long file paths, ApplyMigrationAsync with long directory paths, and MigrationProjectFingerprint content-change detection under long paths. Adds CreateLongDirectoryPath, CreateVeryLongDirectoryPath, and ToWindowsExtendedLengthPath private helpers.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

  • hatayama/unity-cli-loop#1125: This PR extends ThirdPartyToolMigrationFileServiceTests.cs with long-path coverage for the same V3 migration workflow introduced in #1125.
  • hatayama/unity-cli-loop#1181: Both PRs modify source-file reading and caching behavior in the migration pipeline; #1181 adds caching to avoid repeated reads, while this PR routes those reads through the long-path abstraction.
  • hatayama/unity-cli-loop#1376: Both PRs touch MigrationFileFingerprint.Capture and related fingerprint paths; #1376 changes migration plan/fingerprint logic that this PR subsequently routes through ThirdPartyToolMigrationFileAccess.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly matches the main change: fixing migration for deeply nested Windows project files.
Description check ✅ Passed The description is directly related to the long-path migration fix and its validation coverage.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/fix-migration-windows

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
Assets/Tests/Editor/ThirdPartyToolMigrationFileServiceTests.cs (1)

75-230: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a long-path asmdef/asmref regression too.

These cases lock in long-path .cs reads/writes and fingerprinting, but they still leave the assembly-definition/reference discovery path unguarded. A Windows-only long-path .asmdef/.asmref scenario would catch regressions in the remaining migration traversal surface called out in the PR summary.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@Assets/Tests/Editor/ThirdPartyToolMigrationFileServiceTests.cs` around lines
75 - 230, Add a Windows-only long-path regression test for
assembly-definition/reference discovery in
ThirdPartyToolMigrationFileServiceTests. Mirror the existing long-path setup
used by ThirdPartyToolMigrationSourceFileCache and ApplyMigrationAsync, but
create a deeply nested .asmdef or .asmref under the long path and verify the
migration traversal still finds it and includes it in the result. Use the
existing helpers like CreateLongDirectoryPath, ToWindowsExtendedLengthPath, and
the ThirdPartyToolMigrationFileService/ProjectFileInventory flow so the new test
covers the remaining unguarded long-path surface.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@Assets/Tests/Editor/ThirdPartyToolMigrationFileServiceTests.cs`:
- Around line 75-230: Add a Windows-only long-path regression test for
assembly-definition/reference discovery in
ThirdPartyToolMigrationFileServiceTests. Mirror the existing long-path setup
used by ThirdPartyToolMigrationSourceFileCache and ApplyMigrationAsync, but
create a deeply nested .asmdef or .asmref under the long path and verify the
migration traversal still finds it and includes it in the result. Use the
existing helpers like CreateLongDirectoryPath, ToWindowsExtendedLengthPath, and
the ThirdPartyToolMigrationFileService/ProjectFileInventory flow so the new test
covers the remaining unguarded long-path surface.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 44080ed4-cb14-42fc-83dc-86e3aa3b7f3c

📥 Commits

Reviewing files that changed from the base of the PR and between ba97e62 and 28abbb0.

📒 Files selected for processing (14)
  • Assets/Tests/Editor/ThirdPartyToolMigrationFileServiceTests.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationAsmdefMetaGuidReader.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationAsmdefMigrationRequirementResolver.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationAssemblyReferenceResolver.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationAssemblyUsageAnalyzer.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationFastAssemblyRequirementCollector.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationFastSourceTargetDetector.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationFileServiceConstants.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationFileWriter.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationModels.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationPlanBuilder.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationPreflightScanner.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationSourceFileCache.cs
  • Packages/src/Editor/Infrastructure/ThirdPartyToolMigration/ThirdPartyToolMigrationTargetScanner.cs

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 14 files

Re-trigger cubic

@hatayama
hatayama merged commit bd3d7ed into v3-beta Jun 24, 2026
9 checks passed
@hatayama
hatayama deleted the feature/fix-migration-windows branch June 24, 2026 17:25
@github-actions github-actions Bot mentioned this pull request Jun 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant