On Wed, Apr 17, 2024 at 04:10:59PM +0300, Konstantin Komarov wrote:
When counting and checking hard links in an ntfs file record,I also reported seeing link counts being reduced by 2:
struct MFT_REC {
struct NTFS_RECORD_HEADER rhdr; // 'FILE'
__le16 seq; // 0x10: Sequence number for this record.
>> __le16 hard_links; // 0x12: The number of hard links to record.
__le16 attr_off; // 0x14: Offset to attributes.
...
the ntfs3 driver ignored short names (DOS names), causing the link count
to be reduced by 1 and messages to be output to dmesg.
[ 78.307412] ntfs3: nvme0n1p3: ino=34e6, Correct links count -> 1 (3).
[ 78.307843] ntfs3: nvme0n1p3: ino=5bb23, Correct links count -> 1 (2).
[ 78.308509] ntfs3: nvme0n1p3: ino=5c722, Correct links count -> 1 (2).
[ 78.310018] ntfs3: nvme0n1p3: ino=5d761, Correct links count -> 1 (2).
[ 78.310717] ntfs3: nvme0n1p3: ino=33d18, Correct links count -> 1 (3).
[ 78.311179] ntfs3: nvme0n1p3: ino=5d75b, Correct links count -> 1 (3).
[ 78.311605] ntfs3: nvme0n1p3: ino=5c708, Correct links count -> 1 (3).
- https://lore.kernel.org/all/Zhz_axTjkJ6Aqeys@xxxxxxxxxxxxxxxxxxxx/
Are you sure there are not further issues with this code?
For Windows, such a situation is a minor error, meaning chkdsk does notThis patch is white space damaged and does not apply.
report
errors on such a volume, and in the case of using the /f switch, it silently
corrects them, reporting that no errors were found. This does not affect
the consistency of the file system.
Nevertheless, the behavior in the ntfs3 driver is incorrect and
changes the content of the file system. This patch should fix that.
PS: most likely, there has been a confusion of conceptsI'd also expect a Fixes and CC stable tag here.
MFT_REC::hard_links and inode::__i_nlink.
And as this patch does not seem to depend on the rest of the series it
should go first (along with any other bug fixes).
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@xxxxxxxxxxxxxxxxxxxx>Johan