Vim backupcopy choice for retry-safe writes on network filesystems

Question

I need to configure Vim so that an interrupted write to a shared network filesystem leaves the original file intact, while also ensuring that hard links to that file remain valid after a successful save. The documented behavior indicates that writebackup creates a temporary backup before overwriting, and backupcopy determines whether Vim copies the original or renames it to a backup name. When backupcopy is set to auto, Vim may choose rename-based writes on some systems and copy-based writes on others, which introduces uncertainty about whether inode numbers and hard links survive.

The core tension is that rename-based writes avoid momentarily duplicating the full file contents, yet they replace the original inode and break existing hard links. Copy-based writes preserve links but temporarily duplicate data, and some network filesystems may not support the rename semantics atomically. Because behavior can differ across Vim versions and operating systems, I am unsure which documented setting gives a predictable, retry-safe result without silently changing link relationships.

Can Vim be configured to use a single backupcopy strategy that both survives interrupted writes and preserves hard links on filesystems where rename is not atomic? Which option value should be preferred when the priority is avoiding duplicate data rather than preserving inode identity? Does the automatic choice differ between regular files and symlinked targets in a way that can be relied upon across versions?

Tasadduq Burney · Answer

The Recommended Configuration
To ensure that interrupted writes leave the original file intact while preserving hard links on network filesystems, you must use the following settings in your .vimrc:
set writebackup
set backupcopy=yes

Why this combination works
When writebackup is enabled, Vim creates a backup of the file before overwriting it. The backupcopy option determines how that backup is created. By setting backupcopy=yes, you force Vim to copy the original file to a backup location rather than renaming it.

Hard Link Preservation: Because the original file is copied, the original inode remains in place. The write operation then overwrites the existing inode's data. Consequently, all existing hard links to that file remain valid and point to the updated content.
  Retry-Safety: If the write process is interrupted (e.g., a network timeout or crash), the original file remains in its pre-write state because the backup copy provides the recovery point.

Trade-offs and Alternative Strategies

Avoiding Duplicate Data
If your priority is avoiding the temporary duplication of data rather than preserving inode identity, use set backupcopy=no. This uses a rename-based strategy: Vim renames the original file to a backup name and creates a new file for the save. This is more efficient for large files but breaks all hard links and relies on the filesystem's rename() atomicity, which is often unreliable on older network shares (like some NFS versions).

The Risk of backupcopy=auto
The auto setting allows Vim to choose the strategy based on the filesystem. This introduces unpredictability across different operating systems or Vim versions, making it unsuitable for environments where hard-link stability is a requirement.

Symlinks vs. Regular Files
Vim treats symlink targets as the underlying regular file. There is no version-stable difference in how backupcopy handles a symlink target versus a direct file path; the same inode rules apply to the target file.

Verification Steps
You can verify that your configuration is preserving inodes using the following method:

Create a file and a hard link: touch test.txt && ln test.txt link.txt.
  Check the inode number: ls -i test.txt link.txt (they should be identical).
  Open test.txt in Vim with backupcopy=yes, modify it, and save.
  Run ls -i test.txt link.txt again. The inode numbers should remain unchanged.

Diagnostic Note: Please specify the network filesystem protocol (e.g., NFSv3, NFSv4, SMB) if you continue to see file corruption, as some protocols handle file locking and write-atomicity differently regardless of Vim's settings.

Vim backupcopy choice for retry-safe writes on network filesystems

1 answer

The Recommended Configuration

Why this combination works

Trade-offs and Alternative Strategies

Avoiding Duplicate Data

The Risk of `backupcopy=auto`

Symlinks vs. Regular Files

Verification Steps

Your perspective belongs here.

0 question comments