zed
zed copied to clipboard
Zed keeping temporary *~.swift files created by xcode
Check for existing issues
- [x] Completed
Describe the bug / provide steps to reproduce it
When using zed alongside Xcode, I noticed there were random duplicate files being created. For example, I may have had Foo.swift, but then randomly Foo~.swift would appear when I search for something, and when I navigated to it it would exist. I have save on lose focus enabled, so when leaving one of those tabs, it would write the file to disk. This was causing a lot of issues, since swift package manager compiles all *.swift files, and these were included (with duplicate contents).
I dug to the bottom of this using fs_usage and found that xcode is creating these files and then immediately unlinking them. I'm guessing an FS watcher in Zed was opening them up before deleting them (doesn't actually matter too much why).
11:00:16.530787 stat64 /Users/Foo/Bar/Baz~.swift 0.000026 Bar.Agent.13253071
11:00:16.533405 getxattr [ 93] /Users/Foo/Bar/Baz~.swift 0.000045 Xcode.13263549
11:00:16.533426 getattrlist /Users/Foo/Bar/Baz~.swift 0.000018 Xcode.13263549
11:00:16.533446 getattrlist /Users/Foo/Bar/Baz~.swift 0.000015 Xcode.13263549
11:00:16.533959 getattrlist /Users/Foo/Bar/Baz~.swift 0.000030 Xcode.13263549
11:00:16.534546 open F=61 (R___________) /Users/Foo/Bar/Baz~.swift 0.000031 Xcode.13263549
11:00:16.534786 lstat64 /Users/Foo/Bar/Baz~.swift 0.000009 Xcode.13263549
11:00:16.534823 chmod <rw-rw-rw-> /Users/Foo/Bar/Baz~.swift 0.000037 Xcode.13263549
11:00:16.534831 stat64 /Users/Foo/Bar/Baz~.swift 0.000007 Xcode.13263549
11:00:16.534860 getxattr [ 93] /Users/Foo/Bar/Baz~.swift 0.000029 Xcode.13263549
11:00:16.534876 statfs64 /Users/Foo/Bar/Baz~.swift 0.000011 Xcode.13263549
11:00:16.535058 getattrlist /Users/Foo/Bar/Baz~.swift 0.000008 Xcode.13263549
11:00:16.535066 fstatat64 [-2]//Users/Foo/Bar/Baz~.swift 0.000006 Xcode.13263549
11:00:16.535153 open F=36 (R_____N_____) /Users/Foo/Bar/Baz~.swift 0.000015 Bar.Agent.13262359
11:00:16.535213 unlink /Users/Foo/Bar/Baz~.swift 0.000147 Xcode.13263549
(redacted names)
I found a solution/workaround by adding "**/*~.swift" to my file_scan_exclusions. I think this may be a safe thing to upstream as a default since it was only happening with swift files with xcode.
I think @kuglee mentioned a similar issue in this comment https://github.com/zed-industries/zed/issues/17699#issuecomment-2350924803
Zed Version and System Specs
Zed: v0.165.4 (Zed Nightly 2e364ac55b8e41e8e6b5c186679a05249c81fbfb) OS: macOS 15.2.0 Memory: 128 GiB Architecture: aarch64
If applicable, add screenshots or screencasts of the incorrect state / behavior
No response
If applicable, attach your Zed.log file to this issue.
No response
To be clear, you have a project open simultaneously in Zed and in XCode. XCode will create some temporary files and then unlink them (reading #17699; perhaps caused by XCode detecting a file was modified externally by Zed?). Zed is detecting the creation of the file (via FSWatch) but despite them being unlinked 5ms later they are showing up in Zed?
Do you have any steps which can trigger this behavior? Ideally with an open source repo or some such. It sounds like there may be an underlying issue with how Zed is watching files (race condition)?
Workaround of adding "**/*~.swift" to `file_scan_exclusions:
"file_scan_exclusions": [
"**/*~.swift"
"**/.git",
"**/.svn",
"**/.hg",
"**/.jj",
"**/CVS",
"**/.DS_Store",
"**/Thumbs.db",
"**/*~.swift",
"**/.classpath",
"**/.settings"
],
I'm curious, do you know if xcode only do this with .swift files or will it also create these files if it with other filetypes (*.c, *.h, *.json, etc)? Like if we were to add this to default.json file_scan_exclusions should the glob actually be `**/~."?
Sorry for the slow reply @notpeter.
I am unable to consistently trigger the behavior where zed will keep a file open. It happens just sometime.
Zed is detecting the creation of the file (via FSWatch) but despite them being unlinked 5ms later they are showing up in Zed?
Sounds correct. We use some software at work that may be slowing syscalls down which may make this more common.
It seems like editing or opening a file in xcode will sometimes have it open the ~ file. I see zed lstating the new files after they've bene unlinked (this is when I am unsuccessfully reproing them). I imagine if they lstat it before it being unlinked, that may be when the race condition happens.
I'm curious, do you know if xcode only do this with .swift files or will it also create these files if it with other filetypes (*.c, *.h, *.json, etc)? Like if we were to add this to default.json file_scan_exclusions should the glob actually be `**/~."?
I had assumed it was just swift, but I tried a ObjC project, and ran
sudo fs_usage -w -f filesystem | grep '~\.'
and ~.m files came up too, so maybe globbing **/*~.* is more prudent. Not sure how many people are using objc with Zed, but I believe its would be correct to have all *~.* files excluded would be correct.
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!
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.
Sorrry this took so long, would it be possible to reopen this? I just experienced this issue again. I think my proposed fix above would work. Its easy to work around locally, but I imagine this is a bad experience for people who are working on swift
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!
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.