Following up on a question about hardlinks and caching data remotely, I tried a simple experiment: 1) ln /mnt/hardlink1 /mnt/hardlink2 then 2) echo "some data" >> /mnt/hardlink1 then 3) echo "more stuff" >> /mnt/hardlink2 I see the second open (ie the one to hardlink2) fail with STATUS_INVALID_PARAMETER, presumably due to the lease key being reused for the second open (for hardlink2) came from the first open (of hardlink1). It would be logical that leasekeys depend on the inode not that the pathname (so could handle hardlinks on the same mount) but that appears not to be the case. Interestingly the case when two clients access the hardlink (or eg. nosharesock mount to same share on /mnt1 and /mnt2) works more logically: 1) hardlink /mnt1/hardlink1 /mnt1/hardlink2 then 2) nosharesock mount /mnt2 to the same share then 3) echo "some data" >> /mnt1/hardlink1 then 4) echo "more data" >> /mnt2/hardlink2 What you see at step 4 is the open of /mnt2/hardlink2 generates a lease break of the (deferred close) handle on /mnt1/hardlink1 from RWH to RH, and the open of /mnt2/hardlink2 is given RH then after the write to hardlink2 you see a lease break from RH to none as expected before the close. -- Thanks, Steve
