Prevent concurrent file copying#2841
Conversation
|
@BugBot run |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses potential race conditions during file copy operations by introducing a locking mechanism. By wrapping the file copying logic within a lock, it ensures that only one file copy process can execute at a time, thereby enhancing the stability and integrity of file system manipulations within the application. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with π and π on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
π Dyadbot Code Review SummaryVerdict: π€ NOT SURE - Potential issues Reviewed by 3 independent agents: Correctness Expert, Code Health Expert, UX Wizard. Issues Summary
Detailsπ΄ withLock race condition (pre-existing in lock_utils.ts) The Example scenario:
This is not introduced by this PR but limits its effectiveness. A proper fix would use a promise-chain pattern where each caller chains onto the tail of the queue. π‘ Lock key inconsistency All other π« Dropped False Positives (4 items)
Generated by Dyadbot multi-agent code review |
Greptile SummaryThis PR successfully prevents concurrent file copying operations by implementing a per-app locking mechanism and adding symlink traversal security checks. Key Changes:
The promise-chaining implementation correctly ensures that queued operations execute serially by chaining each new operation onto the previous one's completion promise. Confidence Score: 5/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant Caller1 as Caller 1
participant Caller2 as Caller 2
participant ExecuteCopy as executeCopyFile
participant WithLock as withLock
participant FileSystem as File System
Caller1->>ExecuteCopy: executeCopyFile(appId: 1, from, to)
ExecuteCopy->>WithLock: withLock(1, copyOperation)
Note over WithLock: No existing lock<br/>Creates newLock1<br/>locks.set(1, newLock1)
WithLock-->>ExecuteCopy: Promise chained to resolved promise
Caller2->>ExecuteCopy: executeCopyFile(appId: 1, from2, to2)
ExecuteCopy->>WithLock: withLock(1, copyOperation2)
Note over WithLock: Existing lock found (newLock1)<br/>Creates newLock2<br/>locks.set(1, newLock2)<br/>Chains to newLock1
WithLock-->>ExecuteCopy: Promise chained to newLock1
Note over ExecuteCopy,FileSystem: Operation 1 executes
ExecuteCopy->>FileSystem: Validate paths, copy file
FileSystem-->>ExecuteCopy: Success
Note over WithLock: resolve() called<br/>newLock1 resolves<br/>Lock not deleted (newLock2 exists)
Note over ExecuteCopy,FileSystem: Operation 2 executes (after 1 completes)
ExecuteCopy->>FileSystem: Validate paths, copy file
FileSystem-->>ExecuteCopy: Success
Note over WithLock: resolve() called<br/>newLock2 resolves<br/>Lock deleted (no newer lock)
ExecuteCopy-->>Caller1: Success
ExecuteCopy-->>Caller2: Success
Last reviewed commit: 03a2e82 |
- Fix withLock race condition by using promise-chaining instead of await-then-acquire pattern - Use numeric appId instead of appPath string for lock key to share lock domain with other app operations - Add symlink traversal protection using fs.realpathSync to prevent escaping allowed directories Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
@BugBot run |
π€ Claude Code Review SummaryPR Confidence: 4/5All review comments have been addressed with code changes; the lock race condition fix, lock key alignment, and symlink protection are solid but would benefit from integration testing. Unresolved ThreadsNo unresolved threads Resolved Threads
Product Principle SuggestionsNo suggestions β product principles were not needed for these technical/security review comments. π€ Generated by Claude Code |
π Dyadbot Code Review SummaryVerdict: β YES - Ready to merge Reviewed by 3 independent agents: Correctness Expert, Code Health Expert, UX Wizard. The core concurrency fix (promise-chaining in Issues Summary
π’ Low Priority Notes (3 items)
π« Dropped False Positives (5 items)
Generated by Dyadbot multi-agent code review |
| // Copy the file (do not follow symlinks at destination) | ||
| fs.copyFileSync(fromFullPath, toFullPath); |
There was a problem hiding this comment.
π‘ MEDIUM | security / misleading-comment
Misleading comment + missing destination symlink validation
The comment // Copy the file (do not follow symlinks at destination) is incorrect β fs.copyFileSync(src, dest) without any mode flag does follow symlinks at the destination. If toFullPath is or contains a symlink pointing outside the app directory, this call writes the copied content to that external target.
The source path now has thorough symlink-traversal validation via realpathSync, but the destination path (toFullPath) has no equivalent check. This is an inconsistency: an attacker who can create a symlink within the app directory could redirect the copy to overwrite an arbitrary file outside it.
π‘ Suggestion: Either (1) add a realpathSync check on the parent directory of toFullPath after mkdirSync and validate it stays within resolvedAppPath, or (2) remove the misleading comment and note this as a follow-up security hardening task.
π Playwright Test Resultsβ Some tests failed
Summary: 235 passed, 1 failed, 7 flaky, 6 skipped Failed Testsπ macOS
π Re-run Failing Tests (macOS)Copy and paste to re-run all failing spec files locally: npm run e2e \
e2e-tests/select_component.spec.ts
|
closes #2804