mirror of
https://github.com/zed-industries/zed.git
synced 2026-08-31 11:04:43 +00:00
original uri https://github.com/zed-industries/zed
https://zed.dev
e717010c82
Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes #47375 The current `crates/remote/src/transport/wsl.rs` remote transport code tries to copy the remote-server from /mnt/c/* from within WSL. This fails if you have automount disabled, or otherwise have your drive unmounted. How to reproduce this error: Prerequisites: Windows with WSL2 and a WSL distro installed. 1. Inside the WSL distro, disable Windows automount — edit `/etc/wsl.conf`: ```ini [automount] enabled = false ``` 2. From a Windows shell: `wsl --shutdown` 3. Open the distro shell again and confirm `mount | grep /mnt/c` returns nothing. 4. From Zed (any version before this PR), open a remote WSL project on that distro for the first time (no cached `~/.zed_server/zed-remote-server-*` inside the distro — `rm` it if present). The solution was to pipe the server in over stdin if the copy fails. This is a fallback path similar to how ssh.rs has a fallback path if the download fails there. With this PR the logs look like this: ``` 2026-05-24T18:51:37-07:00 INFO [remote::transport::wsl] uploading remote server to WSL ".zed_server/download-72808-remote_server" (441187kb) 2026-05-24T18:51:37-07:00 WARN [remote::transport::wsl] failed to upload remote server via /mnt, falling back to wsl.exe stdin: Command 'Command("wsl.exe" "--distribution" "Ubuntu" "--cd" "~" "--exec" "wslpath" "-u" "C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server")' failed: wslpath: C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server: Command 'Command("wsl.exe" "--distribution" "Ubuntu" "--cd" "~" "wslpath" "-u" "C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server")' failed: wslpath: C:/Users/<user>/Documents/GitHub/zed/target/remote_server/x86_64-unknown-linux-musl/debug/remote_server 2026-05-24T18:51:38-07:00 INFO [remote::transport::wsl] uploaded remote server in 945.899ms ``` I considered making wsl just use curl/wget to download as a fallback, as docker/ssh do, but that would lose the 'cache' effect of downloading once on windows and sending to multiple WSL distros. Which seems to have been the intent of the copy method in the first place. I also considered using the network-drive style UNC mount to copy from Windows to the WSL distro, but that could run into similar issues where the user may have that disabled. It also seems to copy as WSL's default user, rather than the --user specified to Zed for the distro. Currently --user is not passed by default to wsl.exe, so that ends up being the default user. However, it is settable through the settings.json, so some rare users may still have an issue with ownership of the copied files. I chose to make the new stdin option the fallback instead of the default because the current code is working for most people, and it seemed like a much larger change to replace the default. For the tests there don't seem to be any tests for wsl.rs currently that I can find, so it seemed like a lot of extra code needed to satisfy that PR checkbox. wsl.rs and docker.rs have zero inline tests, and the ones that are in ssh.rs don't cover the ensure/upload/download portion. The integration tests seem to use RemoteClient::fake_server and bypass the real transports. For manual testing I tested these scenarios: 1. WSL distro with automount **on** AND existing binary: **still works** 2. WSL distro with automount **on** AND **no** existing binary: **still works** 3. WSL distro with automount **off** AND existing binary: **still works** 4. WSL distro with automount **off** AND **no** existing binary: **now works** I'm not all that proficient with rust so I used a coding agent to help, but I reviewed every line and it all makes sense to me. Please let me know if something looks off, I'm trying to learn. Release Notes: - Fixed remote server installation failing in WSL when automount is disabled. --------- Co-authored-by: Lukas Wirth <lukas@zed.dev> |
||
|---|---|---|
| .agents/skills | ||
| .cargo | ||
| .cloudflare | ||
| .config | ||
| .factory | ||
| .github | ||
| .wezel | ||
| .zed | ||
| assets | ||
| ci | ||
| crates | ||
| docs | ||
| extensions | ||
| legal | ||
| nix | ||
| script | ||
| tooling | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .prettierrc | ||
| .rules | ||
| AGENTS.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CLAUDE.md | ||
| clippy.toml | ||
| CODE_OF_CONDUCT.md | ||
| compose.yml | ||
| CONTRIBUTING.md | ||
| debug.plist | ||
| default.nix | ||
| Dockerfile-collab | ||
| Dockerfile-collab.dockerignore | ||
| Dockerfile-cross.dockerignore | ||
| Dockerfile-distros | ||
| Dockerfile-distros.dockerignore | ||
| flake.lock | ||
| flake.nix | ||
| GEMINI.md | ||
| LICENSE-APACHE | ||
| LICENSE-GPL | ||
| livekit.yaml | ||
| lychee.toml | ||
| Procfile | ||
| Procfile.web | ||
| README.md | ||
| renovate.json | ||
| REVIEWERS.conl | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| shell.nix | ||
| typos.toml | ||
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking discussion)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked.
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.