Fixed hardlink group not being broken on the destination

[wonwuakpa-msft]

Bugs 4, 11, 12 addressed

Logs

AzCopy scenario 4 run log

====================================================================
  Scenario S04: Src B independent | Dst B→A → replace B with independent file
  Direction: L2N
====================================================================
----- INITIAL -----
[SRC = /home/azureuser/hltest-local/src-s04]
  786934 1 /home/azureuser/hltest-local/src-s04/B
[DST = /home/azureuser/nfsmp/dst-s04]
  10682608684867125801 2 /home/azureuser/nfsmp/dst-s04/A
  10682608684867125801 2 /home/azureuser/nfsmp/dst-s04/B

----- AzCopy copy --hardlinks=preserve -----
Src: /home/azureuser/hltest-local/src-s04
Dst: https://ucexsapsat20py02cx.file.preprod.core.windows.net/nfssharetestazcopy1/dst-s04?XX
INFO: The --hardlinks option is set to 'preserve'. Hardlinked files will be preserved as hardlinks at the destination.
INFO: Note: The preserve-permissions flag is set to false. As a result, AzCopy will not copy NFS permissions between the source and destination.
INFO: Any empty folders will be processed, because source and destination both support folders. For the same reason, properties defined on folders will be processed
INFO: Scanning...

Job 7fa4d08d-6092-394f-74db-be172bb41606 has started
Log file is located at: /home/azureuser/.azcopy/7fa4d08d-6092-394f-74db-be172bb41606.log

INFO: Trying 4 concurrent connections (initial starting point)
100.0 %, 2 Done, 0 Failed, 0 Pending, 0 Skipped, 2 Total, 2-sec Throughput (Mb/s): 0.0001


Job 7fa4d08d-6092-394f-74db-be172bb41606 summary
Elapsed Time (Minutes): 0.0333
Number of File Transfers: 1
Number of Folder Property Transfers: 1
Number of Symlink Transfers: 0
Total Number of Transfers: 2
Number of File Transfers Completed: 1
Number of Folder Transfers Completed: 1
Number of File Transfers Failed: 0
Number of Folder Transfers Failed: 0
Number of File Transfers Skipped: 0
Number of Folder Transfers Skipped: 0
Number of Symbolic Links Skipped: 0
Number of Hardlinks Converted: 0
Number of Hardlinks Transferred: 0
Number of Hardlinks Completed: 0
Number of Hardlinks Failed: 0
Number of Hardlinks Skipped: 0
Number of Special Files Skipped: 0
Total Number of Bytes Transferred: 24
Final Job Status: Completed

AzCopy exit code: 0
----- AFTER -----
[SRC = /home/azureuser/hltest-local/src-s04]
  786934 1 /home/azureuser/hltest-local/src-s04/B
[DST = /home/azureuser/nfsmp/dst-s04]
  10682608684867125801 2 /home/azureuser/nfsmp/dst-s04/A
  10682608684867125801 2 /home/azureuser/nfsmp/dst-s04/B

  [FAIL] B independent: /home/azureuser/nfsmp/dst-s04/B link-count=2 (expected 1)
  [FAIL] A,B not linked: /home/azureuser/nfsmp/dst-s04/A and /home/azureuser/nfsmp/dst-s04/B share inode 10682608684867125801 (should be unlinked)
  [FAIL] A content: /home/azureuser/nfsmp/dst-s04/A md5=0a6d975e8f366bdb79bd1816e21750ba (expected dc0ca1d2973f4cf1da91ccc811c2104d for payload)
  [PASS] B content: /home/azureuser/nfsmp/dst-s04/B content matches expected
----- S04 result -----
  Pass: 1   Fail: 3
  RESULT: SCENARIO FAILED

Root Cause

When performing copy --hardlinks=preserve with a source that has file B as independent and destination with A+B in a hardlink group, AzCopy was not unlinking B from the destination hardlink group to match the source. This was because the Create File call was called on the already existing destination path and it would preserve the destination inode (therefore keeping it in the same hardlink group).

Bug Fix

We now unlink anchor files from its group before creating it. We call .Delete() on the file before proceeding to the existing Create call. This now leaves B as an independent file to match the source as expected.

[Copilot]

Pull request overview

This pull request fixes an Azure Files NFS hardlink-preservation edge case where overwriting an existing destination path could unintentionally preserve the destination inode (and therefore keep/affect an existing hardlink group), causing the destination hardlink topology and/or content to diverge from the source.

Changes:

• For Azure Files NFS transfers, detect when the destination path is part of a hardlink group (LinkCount > 1) and delete it before Create to ensure the hardlink group is broken when overwriting that path.
• Add new NFS end-to-end scenarios validating that destination hardlink groups are correctly broken/split to match source topology.
• Add/clarify hardlink handling enum documentation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

File	Description
ste/sender-azureFile.go	Deletes destination NFS files that are part of a hardlink group before recreating, preventing inode preservation from keeping unintended hardlink relationships.
e2etest/zt_newe2e_nfs_scenarios_test.go	Adds new NFS scenarios and a helper to validate LinkCount/FileID via SDK properties.
common/fe-ste-models.go	Adds a clarifying comment for HardlinkHandlingType.Preserve().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.