Fix file watching for symlinked workspace on Linux

[tancop]

• Closes Symlink as workspace root breaks file watching #17161

• Fix file watching for symlinks #17609 only fixed file watching for symlinks inside the workspace, not if the folder itself or one of its parents is a symlink. This PR replaces uses of read_link with canonicalize that returns the right canonical path in these cases.

Release Notes:

• Fixed file watching for symlinked workspaces on linux

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @tancop on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[tancop]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[tancop]

@notpeter I rebased and fixed the failing tests, should check for rename events not just delete. Can you run CI again?

[tancop]

@ConradIrwin

[tancop]

All tests passed, do you think this is ready for merge?

[tancop]

@maxdeviant

[ConradIrwin]

@tancop sorry for the glacial response here!

The change to canonicalize before calling watch makes sense to me; do we also need to canonicalize on every filesystem event? It sounded like from your description on the issue that we were already getting canonical paths in that situation?

[tancop]

@ConradIrwin I rebased on the fs refactor and skipped canonicalize unless the root path is a symlink or the event path we got from notify doesn't match. Not exactly elegant but it works

[ConradIrwin]

@tancop Thanks!

Why is that needed? It sounded like from your earlier notes that we already got canonical paths from the notify events?

Can you also help me nail down the reproduction steps please: #17161 (comment)

[tancop]

@ConradIrwin delete and rename events can return non canonical paths because the file doesn't exist anymore so notify can't canonicalize it internally. Same thing happens when the root directory is a descendant of a symlink for whatever reason, I tried to remove that check but it broke.

For the reproduction steps:

• Create a directory
• Create a symlink to that directory
• Open the symlink in Zed
• Create a file in the original directory outside of Zed (touch, vscode, file manager)
• Zed doesn't detect the file

[tancop]

@ConradIrwin do i also need to change repro steps on the issue?

[ConradIrwin]

@tancop I feel like I'm missing something obvious, but I cannot reproduce this problem as you describe....
Screencast from 2024-11-19 08-46-42.webm

Is there something different about our setups, or is there something else I need to do to get into the broken state?

[tancop]

@ConradIrwin I tested it with your commands and everything works that way. It breaks when I open the same folder with the recents picker inside zed so the real issue might be in there.

[ConradIrwin]

Aha!

In that case, I think #21039 is probably a better fix. We can avoid this state entirely by opening the target of the symlink (as we do when you run zed from the command line).

[tancop]

@ConradIrwin thanks for the link!

Closed in favor of #21039