Repository navigation
Let a MountCore handle go when its landing at release fails - #1637
Merged
Merged
Conversation
MountCore.release flushed and then popped the handle, so a flush that raised (a pwrite a policy or mount mode refuses, a backend error) left the handle in the table for good. No adapter retries a release: the kernel ignores a RELEASE error, sshfs never waits for its FXP_CLOSE reply, and codex releases once in a finally. The handle and its bytes stayed until the core went away. Release now pops the handle whatever the flush did, as close(2) frees its descriptor even when it reports an error, and still raises the failure to the adapter. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
[Medium impact] The PR appears safe to merge; failed releases free their handles while preserving error reporting.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MountCore.releaseflushed the handle and then popped it, on both hosts. If the flush raised, the pop never ran. That happens when a pwrite is refused by a policy or a mount mode (opening an existing file for write withoutO_TRUNCchecks neither), or when the backend fails. The handle and its buffered bytes then stayed in the table until the core went away, because no adapter retries a release:release, and sshfs never waits for the FXP_CLOSE reply.finally.releasenow pops the handle in afinallyand still raises the failure to the adapter. This follows Linux close(2), which frees the descriptor even when it reports an error.Found while working on #1636. Its
MountCore.syncruns at the end of every sandbox line, and it would otherwise have retried such a leaked handle and logged a warning after every line. This change is independent of #1636 and is based on main.Test plan
tests/mount/test_core.pyand TScore.test.ts: on a read-only workspace, a release whose landing is refused raises, the handle is gone, and the file still holds its old bytes. Both tests fail on main.tscfor node.🤖 Generated with Claude Code