Files
seaweedfs/test
Chris LuandGitHub c8433a19f0 fix(mount): propagate hard-link nlink changes to sibling cache entries (#9062)
* fix(mount): propagate hard-link nlink changes to sibling cache entries

weed mount serves stat from its local metacache, and the kernel also
caches inode attrs from FUSE replies. When a hard link was unlinked or
a new link added, the filer updated the shared HardLink blob correctly,
but the sibling link entries in the mount's metacache still carried the
stale HardLinkCounter and the kernel attr cache on the shared inode was
not invalidated. Subsequent lstat on any sibling link returned the old
nlink — pjdfstest link/00.t caught this after `unlink n0` and on
`link n1 n2` stating n0.

Walk every path bound to the hard-linked inode via a new
InodeToPath.GetAllPaths, rewrite each cached sibling's HardLinkCounter
and ctime to the authoritative new value, and call
fuseServer.InodeNotify to invalidate the kernel attr cache for the
shared inode. Applied from both Link (bump) and Unlink (decrement).

Unblocks tests/link/00.t and tests/unlink/00.t in pjdfstest; full suite
(235 files, 8803 tests) passes end-to-end with no regressions.

* fix(mount): harden hard-link sibling sync against nil Attributes and id mismatch

Review follow-ups:
- Unlink: guard entry.Attributes for nil before reading Inode, with a
  fallback to inodeToPath.GetInode resolved before RemovePath. Fold the
  duplicated RemovePath into a single call.
- syncHardLinkSiblings: skip siblings whose HardLinkId does not match
  the authoritative entry. The shared-inode invariant normally
  guarantees a match, but a transient mismatch (e.g. a rename replaced
  one of the paths) would otherwise stamp an unrelated entry with the
  wrong counter.

Full pjdfstest suite still passes (235 files, 8803 tests).
2026-04-13 18:40:57 -07:00
..
2026-03-09 23:10:27 -07:00
2026-04-10 17:31:14 -07:00
2026-04-10 17:31:14 -07:00
2026-03-09 11:12:05 -07:00
2023-11-13 08:23:53 -08:00
2026-04-10 17:31:14 -07:00