buffer: Store potential resolved symlinks as AbsPath
#3997
Conversation
|
I've noticed an "issue" with this PR. If we have a regular file For comparison, vim shows the resolved file name in the statusline, so it behaves predictably: it always shows the original file name. Well, maybe we can treat this as a feature ("first wins" rule)... |
Hm, indeed...this behavior is somehow strange. EDIT: EDIT2: |
|
Hmmmm... what is this? https://pkg.go.dev/path/filepath#EvalSymlinks :) Worth checking if we can just use this? Also, just realized: we should resolve each component of the path (i.e. each directory), not just the last one (the file itself), since any of the directories may be a symlink too? And skimming through the code in https://github.com/golang/go/blob/master/src/path/filepath/symlink.go it looks like this |
Whaaat...feels like this came out of nowhere. Don't know, why I didn't see this myself, especially since I had [filepath](the https://pkg.go.dev/path/filepath) documentation the last days open again. Thank you for pointing me to this link! |
JoeKar
force-pushed
the
fix/symlinks
branch
2 times, most recently
from
5e77c5a to
9191df8
Compare
Otherwise we can't identify if we have the same file open multiple times via different symlinks. The test must be adapted to resolve symlinks in `findBuffer()`.
Otherwise it will be removed async, which shouldn't happen in case there is still one buffer open with the same modified file.
Otherwise we unnecessarily serialize the shared buffer every time when closing a bufpane with this buffer, so every such serialize overwrites the previous one, thus only the last serialize (when closing the last instance of the buffer, i.e. when actually closing the file, i.e. when the buffer is not shared anymore) will be used anyway.
2 participants
This will help us to keep track of the same file opened via different symlinks.
Fixes #3995