Re: [PATCH v5 11/31] ntfs: handle source record removal failure during attribute moves

[Xuewen Wang <wangxuewen_ky@163.com>]

在 2026/11/10 12:11, Namjae Jeon 写道:
> On Tue, Nov 10, 2026 at 12:13 PM Xuewen Wang <wangxuewen_ky@163.com> wrote:
>>
>>
>>
>> 在 2026/11/9 10:31, Hyunchul Lee 写道:
>>> On Mon, Nov 02, 2026 at 03:35:12PM +0800, Xuewen Wang wrote:
>>>> From: Xuewen Wang <wangxuewen@kylinos.cn>
>>>>
>>>> ntfs_attr_record_move_to() ignores failure to remove the source attribute
>>>> after copying it. It can update the attribute-list reference and report
>>>> success with both copies present.
>>>>
>>>> Check removal before changing the list entry. On failure, attempt to
>>>> remove the destination copy, mark its record dirty and unmap it, leaving
>>>> the list pointing to the source. Report destination cleanup failure
>>>> separately.
>>>>
>>>> Shrinking a record to zero needs no extra space, so failure indicates
>>>> inconsistent record accounting. Return and report EFSCORRUPTED even if
>>>> cleanup also fails.
>>>>
>>>> Fixes: 495e90fa3348 ("ntfs: update attrib operations")
>>>
>>> This patch has the Fixes tag, but it calls
>>> ntfs_report_file_metadata_error(), which is introduced in patch 3.
>>> If this patch is backported to a stable tree with patch 3, it could fail
>>> to build.
>>>
>> Hi Hyunchul,
>>
>> Thank you for your review. You are right about the dependency.
>>
>> Would it make sense to reorganize the series so that the bug-fix patches
>> come first and use the existing error-handling mechanisms, without
>> depending on the new reporting helpers?
> Yes. So I would like to apply error handling patches first and check
> new report helpers later.
>>
>> I would then add calls to the new helpers at those sites in a separate
>> patch at the end of the series.
> Okay.
>>
>> Would this approach work for you?
> Yes, Please do that.
> Thanks.
Hi Namjae,
Thanks for your reply. Baolin, Dandan and I will proceed with the 
changes following this plan and send out v6 as soon as possible.

Thanks,
Xuewen