Repository navigation
Conversation
Clients attached to a remote server expanded ~ in /cd against their own home directory, so a macOS client sent /Users/... paths to a Linux server. The server never reported its home, leaving remote clients no authoritative value to expand against. - Location.Info gains an optional home field, populated by location.get and the response wrapper from the server's Global home - the TUI /cd handler and directory autocomplete expand ~ against the synced location home, falling back to the client home for local or older servers - the web app fills its path.home placeholder from the reported value
The server home now reaches the tab preview through loadPathQuery, so the previously dead abbreviation branch runs for every connection. Anchor it on the path prefix like the other home consumers instead of replacing the first substring occurrence, which could rewrite a directory that merely contains the home path.
Wrapped endpoints encode through Location.response, whose PublicRef carries only the directory, so the home field set in the response wrapper never reached the wire. home is reported exclusively by location.get, and the test now locks that split: location.get carries home while wrapped responses carry only the directory.
…ty home The workerd runtime reports os.homedir() as an empty string, which is not nullish, so it would win the ?? chain and expand ~ against nothing. Treat it as absent and fall through to the client home.
Contributor
|
The following comment was made by an LLM, it may be inaccurate: |
Contributor
|
Thanks for tracking this down and for the clear write-up! I think this duplicates #55203, which was opened earlier for the same issue (#55171) and is still being worked on:
Your version puts |
Author
|
Thanks. That PR was created just 4hrs ago and I didn't notice. |
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.
Issue for this PR
Closes #55171
Type of change
What does this PR do?
/cd ~in the TUI expanded~against the client's home directory beforesending it to the server. A macOS client attached to a Linux server therefore
sent
/Users/<user>paths to a machine where they don't exist, and thedirectory change failed with
Location not found: /Users/<user>.The root cause was two-fold: the client expanded too early with the wrong
home, and the server never reported its home directory — so a remote client
had no authoritative value to expand against. (
packages/appeven carried ahome: ""placeholder inloadPathQuery, waiting for the server to reportit.)
Same bug family as #47665 (client-side path resolution while attached to a
remote server), hit through the
/cdslash command's tilde expansion.Location.Infogains an optionalhomefield. Optional sonewer clients still decode older-server responses during version skew;
excess-property stripping keeps old clients safe against newer servers.
location.getreportshomefromGlobal.Service, yielded inthe handler group generator (build time) so per-request effects keep
requiring only middleware-provided services.
/cdhandler and directory autocomplete expand~/~/...against the synced location home, falling back to the client home only for
local servers or servers that don't report a home.
loadPathQueryfills its long-standinghome: ""placeholder fromthe reported value, which brings the server-home-aware picker and display
paths to life.
(
packages/protocol,services/www).homeis reported exclusively bylocation.get: wrapped endpoints encodethrough the
Location.response/PublicRefwrapper, which carries only thedirectory, so stamping it there never reached the wire (an earlier iteration
did; a test now locks the split in both directions).
How did you verify your code works?
Test cases run, attachment from client run.
Screenshots / recordings
If this is a UI change, please include a screenshot or recording.
Checklist
If you do not follow this template your PR will be automatically rejected.