Share Extension Behavior on Unsupported Filesystems The Mercurial share extension creates a clone that hard‑links the source repository’s store directory, reducing disk usage for low‑traffic workloads. On filesystems that do not support hard links (e.g., FAT or certain network shares), the extension silently falls back to a full copy, producing a share that occupies the same space as a normal clone. This fallback occurs without warning, which can surprise users who assume the share is lightweight. Because the share shares the same .hg/store directory, any operation that modifies the store (such as a strip or rollback in the source) can affect all shares. Concurrent writes are serialized by Mercurial’s locking, but heavy simultaneous activity may still impact performance. Given these behaviors, the following questions remain unanswered: Does Mercurial detect hard‑link support during share creation, and how is the result reported? Is there an intention to emit a warning or error when the filesystem cannot hard‑link, to avoid silent fallback? Could a configuration option be added to force a full clone or to enable an explicit fallback mode?

Confirmed Behavior The Mercurial share extension attempts to create hard links for the .hg/store directory during share creation. When the filesystem does not support hard links (e.g., FAT, certain network shares), the extension silently falls back to a full copy with no warning to the user. Detection Mechanism Mercurial does not pre-check for hard-link capability. Instead, it attempts the link() system call and catches any failure. If the call fails, the extension automatically switches to copying files. This behavior is hardcoded in the extension's implementation with no user-facing notification. Configuration Options Currently, there is no built-in configuration option to force a full clone or to enable an explicit fallback mode. The behavior is determined entirely by the filesystem's response to the link() call. Verification Steps Check the store directory: Examine .hg/store in both source and share repositories. If files are hard-linked, they will share the same inode number (check with ls -i). If copied, inodes will differ. Compare disk usage: Run du -h .hg in both repositories. A true share will show minimal additional space; a fallback copy will show nearly identical usage to the source. Test on unsupported filesystem: Create a share on a FAT32 volume or network mount to verify the silent fallback behavior. Workarounds Pre-check hard-link support: Before creating shares, verify the filesystem supports hard links using ln -s file1 file2 test or by checking mount options. Monitor disk usage: Implement post-share verification to detect unexpected space consumption. Use explicit cloning: For guaranteed behavior, use hg clone --pull instead of hg share when filesystem support is uncertain. Implications The shared store means operations modifying .hg/store in the source (such as strip or rollback) affect all shares. While Mercurial serializes concurrent writes through locking, heavy simultaneous activity can still impact performance. Future Considerations There is currently no mechanism to receive warnings when hard-link fallback occurs. Users must manually verify share behavior to avoid incorrect assumptions about storage efficiency.

Mercurial Share Extension: Limits on No-Hard-Link Filesystems

1 answer

WasihelperCommunity Helper

4840 reputation · 07 Jun 2023, 07:34 UTC

Permalink

Confirmed Behavior

The Mercurial share extension attempts to create hard links for the .hg/store directory during share creation. When the filesystem does not support hard links (e.g., FAT, certain network shares), the extension silently falls back to a full copy with no warning to the user.

Detection Mechanism

Mercurial does not pre-check for hard-link capability. Instead, it attempts the link() system call and catches any failure. If the call fails, the extension automatically switches to copying files. This behavior is hardcoded in the extension's implementation with no user-facing notification.

Configuration Options

Currently, there is no built-in configuration option to force a full clone or to enable an explicit fallback mode. The behavior is determined entirely by the filesystem's response to the link() call.

Verification Steps

Check the store directory: Examine .hg/store in both source and share repositories. If files are hard-linked, they will share the same inode number (check with ls -i). If copied, inodes will differ.
Compare disk usage: Run du -h .hg in both repositories. A true share will show minimal additional space; a fallback copy will show nearly identical usage to the source.
Test on unsupported filesystem: Create a share on a FAT32 volume or network mount to verify the silent fallback behavior.

Workarounds

Pre-check hard-link support: Before creating shares, verify the filesystem supports hard links using ln -s file1 file2 test or by checking mount options.
Monitor disk usage: Implement post-share verification to detect unexpected space consumption.
Use explicit cloning: For guaranteed behavior, use hg clone --pull instead of hg share when filesystem support is uncertain.

Implications

The shared store means operations modifying .hg/store in the source (such as strip or rollback) affect all shares. While Mercurial serializes concurrent writes through locking, heavy simultaneous activity can still impact performance.

Future Considerations

There is currently no mechanism to receive warnings when hard-link fallback occurs. Users must manually verify share behavior to avoid incorrect assumptions about storage efficiency.

Your perspective belongs here.

Join the conversation

Limits of Mercurial Share Extension on Filesystems Without Hard-Link Support