At Hard Links and Junctions MSDN article one can read the following:
A hard link is the file system representation of a file by which more than one path references a single file in the same volume. To create a hard link, use the CreateHardLink function. Any changes to that file are instantly visible to applications that access it through the hard links that reference it. However, the directory entry size and attribute information is updated only for the link through which the change was made. Note that the attributes on the file are reflected in every hard link to that file, and changes to that file's attributes propagate to all the hard links. For example if you reset the READONLY attribute on a hard link to delete that particular hard link, and there are multiple hard links to the actual file, then you will need to reset the READONLY bit on the file from one of the remaining hard links to bring the file and all remaining hard links back to the READONLY state.
Can someone make sense out of the above paragraph?
Isn't the statement attributes on the file are reflected in every hard link to that file equivalent to the statement changes to that file's attributes propagate to all the hard links?
How come resetting READONLY bit can bring the file and all remaining hard links back to the READONLY state?
After reading JdeBP's excellent answer to this question I'm still left with doubts.
I understand there's a partial copy of MFT's
$STANDARD_INFORMATION entry for each hard link pointing to this entry which according to the answer isn't even kept up to date unless a hard link is renamed, created, or destroyed. What does happen when one reads attributes of a hard link? I guess this hard link's copy of
$STANDARD_INFORMATION is ignored as it might not reflect the current state and attributes are being read directly from the MFT's entry's
$STANDARD_INFORMATION. Additionally during this process no information is updated as it's not any of operations you listed. Is it so?
If one sets the R bit off in order to enable deleting a hard link to the file, then (presuming that that wasn't the last link) one has to set the R bit back on again, in whatever way, to make the file read-only again.
Now, I don't get the presuming that that wasn't the last link part. I don't see how the link being the last one makes any difference here. There's still a file (MFT's entry) itself and one can change its attributes directly (not through any link). Or is it so that if there's a file there's a link meaning there's no one to one correspondence between MFT's entries and files?