Zed follows file moves made outside of Zed (e.g., using the `mv` command from the command line).

[zzl0]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

Update: check the description here

Original description:

I am using Sapling (sl) as source control system. Reproduce steps:

$ sl clone https://github.com/zed-industries/zed.git
$ cd zed
$ sl st
$ echo 111 >> README.md
$ sl st
M README.md
$ sl diff
diff --git a/README.md b/README.md
--- a/README.md
+++ b/README.md
@@ -47,3 +47,4 @@
 ...
+111
$ # open README.md in zed editor
$ sl revert .
reverting README.md
$ # README.md's content did not change after `sl revert`. 

sl revert basically does two things: (1) moves the file to a hidden backup folder (2) restore the content of the file.

It seems zed follows the file moves. For example, assume I have a file foo, and opens it in zed editor. If I move it to 'bar' (mv foo bar), then the filename in the zed editor becomes bar instead of showing foo is removed (vs code has the expected behavior). Zed might tracks the inode of the file.

Environment

I am running zed on Mac M1 laptop.

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

No response

[mmtftr]

Personally, I prefer the tracking of the file moves. Perhaps a setting might be added for this functionality though?

[zzl0]

@mmtftr thanks for the reply

Personally, I prefer the tracking of the file moves. Perhaps a setting might be added for this functionality though?

I respectfully disagree with that perspective. From a user's standpoint, I am more care about the file path I opened. I'd prefer keeping the path by default when a file is moved from command line (not via Zed rename feature):

1. If the file was moved and recreated, then show the content of the new file (same file path) and mark it as modified instead of tracking the moved-to file.
2. If the file was just moved, then mark as deleted or moved instead of changing the file path silently.

I prefer the tracking of the file moves

Out of curiosity, why do you want this? this would be a surprise to me, I am not aware of any editors doing this (silently changing the file path when file is moved). And this would be a blocker for some use cases, I don't want to search and update a setting for this not uncommon use case.

[mmtftr]

On macOS, all apps that I know do this. So if you had something open in Preview, and that thing moved to another folder, then Preview would still have the same file open. You can do this with a lot of apps and most apps work off of file objects, not file paths.

I don't have a use case but this pattern itself is something that I'm used to and makes sense to me. I don't really do a lot of command line mvs of files in my codebases, when I do though I'd like the editor to point to the new file instead. That's because I'm still editing the same object, it's just that it's moved to another folder.

[zzl0]

It seems we are talking about different things.

The use case I described in this issue is file moves made outside of Zed, for example, running mv command from command line. I have tried it on VS Code and Sublime, both of them showed the original file was deleted.

So if you had something open in Preview, and that thing moved to another folder, then Preview would still have the same file open.

If users use the rename feature inside Zed app, it's perfectly fine and makes sense to follow the moves.

I don't really do a lot of command line mvs of files in my codebases, when I do though I'd like the editor to point to the new file instead. That's because I'm still editing the same object, it's just that it's moved to another folder.

It might be useful in some cases, but it can be a blocker for many valid use cases.

Below is comparison between Zed (left) and VS Code (right) after I ran 'mv a.txt b.txt' on command line.

[glensc]

Similar bug (and real-life use-case):

• https://github.com/zed-industries/zed/issues/17570

[zzl0]

Similar bug (and real-life use-case):

• Very nasty bug with vim interop #17570

Thanks for sharing, I also updated the title of this issue

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and we will keep it open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, we'll close it in 7 days. Thanks for your help!

[mikayla-maki]

Thanks for the bug report! This one seems pretty tricky, since Zed is doing too-good of a job of tracking files. I wonder if we could special case "move + creation of file at the same path" so that tools relying on these behaviors don't break...

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and we will keep it open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, we'll close it in 7 days. Thanks for your help!

[glensc]

Not stale

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and we will keep it open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, we'll close it in 7 days. Thanks for your help!

[github-actions[bot]]

This issue was closed due to inactivity. If you're still experiencing this problem, please open a new issue with a link to this issue.