How do I keep file ownership and metadata stable when Vim writes through symlinks?

Explanation

When Vim saves a file, it may use a rename-style write strategy that can replace the original inode. In symlinked paths, network mounts, or files with strict metadata expectations, this can cause ownership, permissions, or watcher behavior surprises. Setting backupcopy=yes tells Vim to write by copying over the original file, which is often safer in these environments.

How it works

• backupcopy controls how Vim writes files when backups are involved
• yes forces copy-and-overwrite behavior instead of rename-replacement
• This helps preserve expected file identity and metadata semantics in workflows that are sensitive to inode swaps

Example

If you edit a symlinked config file managed by deployment tooling, use:

:set backupcopy=yes

Then save normally with :write. The target file is updated in a way that is less likely to break ownership assumptions or file watcher integrations.

Tips

• Make it project-local when needed: :setlocal backupcopy=yes
• Persist globally in config if you regularly edit on network filesystems
• Check current value with :set backupcopy?
• Related options: backup, writebackup, and backupskip