Fix mount timeout when auth/network is slow#2034
Open
tyrielv wants to merge 1 commit into
Open
Conversation
tyrielv
force-pushed
the
tyrielv/mount-timeout
branch
from
994c625 to
223b028
Compare
The MountVerb used a single 60s pipe-connect call without process tracking, causing 'GVFS.Mount process is not responding' errors even when the mount process was alive but blocked on network retries. Changes: - MountVerb now passes a process-tracking delegate to WaitUntilMounted (the same mechanism previously added for GVFS.Service automount), enabling fast-fail on process exit and short-interval connect retries instead of a single blocking 60s connect. - Auth/network retry progress is now surfaced in the mount status message visible to the user via GetStatus polling, so they can see issues like '401 Unauthorized, retrying (attempt 2/7)...' and choose to kill the mount early rather than waiting blindly. The pipe-connected GetStatus polling loop is already unbounded (waits indefinitely while mount reports progress), so once the pipe connects, slow network operations no longer cause timeouts — users just see live status updates instead of a frozen 'Mounting...' spinner. Assisted-by: Claude Opus 4.6 Signed-off-by: Tyrie Vella <tyrielv@gmail.com>
tyrielv
force-pushed
the
tyrielv/mount-timeout
branch
from
223b028 to
95cc5ad
Compare
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
1 participant
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.
A user reported 'Unable to mount because the GVFS.Mount process is not responding' when authentication issues before the mount pipe was opened took more than the 60s we currently wait for the pipe to open. A previous PR already partially addressed this by moving the named pipe opening earlier in the mount process, but we can do more.
Fix
MountVerb now uses process tracking - passes a
MountProcessSnapshotdelegate toWaitUntilMounted, the same mechanism previously added for the GVFS.Service automount path. This enables:We previously implemented process tracking for GVFS.Service (automount), but hadn't incorporated it into regular user-initiated mounts.
Auth/network retry progress surfaced to user - The
ConfigHttpRequestorretry loop now reports failures and retry attempts into the mount progress message (viaonRetrycallback). Users see live status like 'Network: Server returned 401 (Unauthorized), retrying (attempt 2/7)...' instead of a frozen 'Mounting...' spinner. This lets them Ctrl+C early if auth is broken rather than waiting 3+ minutes for retries to exhaust.