buffer: Store potential resolved symlinks as AbsPath
#3997
Conversation
internal/util/util.go
Outdated
| return filename, err | ||
| } | ||
| if !filepath.IsAbs(dstFilename) { | ||
| filename = filepath.Join(filepath.Dir(filename), dstFilename) |
There was a problem hiding this comment.
Do we really need to resolve relative path to absolute one?
And even if we do, why need to do that at each iteration, not just at the end?
There was a problem hiding this comment.
Do we really need to resolve relative path to absolute one?
From my perspective yes, because we compare it at the end against the buffers AbsPath and it shall not be affected by any relative link or whatever.
This doesn't mean that we have to do this within this function. We can also do this in the using function.
And even if we do, why need to do that at each iteration, not just at the end?
Obviously no. 🤦♂️
EDIT:
In an intermediate state I had an issue caused by layer 8 (me), which lead me to a wrong assumption.
There was a problem hiding this comment.
This doesn't mean that we have to do this within this function. We can also do this in the using function.
I would prefer to do this at the end of ResolveSymlinks().
There was a problem hiding this comment.
Obviously no. 🤦♂️
Actually I've recalled that we do need to do that at each iteration, since any intermediate symlink may be relative too. (And that is the actual reason why resolving to absolute path needs to be done by ResolveSymlinks(), not just by the caller.)
|
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)... |
Otherwise we can't identify if we have the same file open multiple times via different symlinks. Additionally this will also store the buffer backup and serialized buffer for the same target file just once.
Otherwise it will be removed async, which shouldn't happen in case there is still one buffer open with the same modified file.
Hm, indeed...this behavior is somehow strange. EDIT: EDIT2: |
Otherwise we do unnecessarily serialize per shared buffer as well as storing multiple cursor states, while only the last one will be restored anyway.
2 participants
This will help us to keep track of the same file opened via different symlinks.
Fixes #3995