Neither a "Fixes:" tag, a "stable" tag[1], nor a proper commit message on a #Linux #kernel commit[2] that afaics fixes a ntfs3 regression[3] where data added to a newly created file only becomes visible after a remount or a forced cache drop[4].

#Sigh

[1] this thus is unlikely to be fixed in 6.6.y or 6.7.y

[2] https://git.kernel.org/torvalds/c/d68968440b1a75dee05cfac7f368f1aa139e1911 (the last one of a series)

[3] introduced in #LinuxKernel 6.2-rc1

[4] https://bugzilla.kernel.org/show_bug.cgi?id=218180 (happens when compression is used)

@kernellogger And no description in the commit message: so nothing explaining *why* this patch is needed, only stating the "obvious" in the title :'(

@kernellogger probably because no reviews have been done?

@kernellogger about the backports to stable, I know that some subsystems prefer to send patches to the stable team, and not having the stable team to do that "automatically" by looking at the commits. But I don't know what's being done here with NTFS3.

@matttbe

It was posted for review, but nobody looked closer afaics (guess the number of devs that care about ntfs3 is close to zero): https://lore.kernel.org/all/dedce962-d48d-41d6-bbbf-e95c66daba80@paragon-software.com/

Not sure if Linus did not notice, did not care, or if he simply thought something along the lines of "I better take this without complaining, as I otherwise sooner or later might not get any fixes as at anymore"

@matttbe

Those should be in this list:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list?id=9bf1f8f1ca9ae53cf3bc8781e4efdb6ebaee70db

But yes, it's possible. But I doubt that will happen given the lack of a proper commit message and fixes tags… but maybe I'm wrong.

@kernellogger Social network is wrong place to comment on this. AUTOSEL picks up a lot of non-fixes, it may pick this. If not, you can write to stable mailing list if you care.

@pavel

I understand and fully respect why you say that, but in this case I disagree:

Sometimes trying to address a problem is pretty hopeless[1] -- or you lack time and energy to address it. That does not mean you are not allowed to talk about the problem.

[1] among the reasons for that:
* participation in stable always has been as still is optional
* ntfs3 maintenance is known to have problems, some of which are bigger then this

@kernellogger @matttbe I would say, that anyone can suggest material for backports to stable, you can even suggest the missing commit description. I've never had problem suggesting fixes, always smooth experience.

@ynezz @matttbe

I'm well aware of that and do that regularly (and might do that here as well, not sure yet). But when it comes to file systems one needs to be extra-careful -- and a missing patch description does not help here.

@kernellogger One email to stable team should not be harder than one post on social media. Anyway, these are in AUTOSEL now.

6.1 01/28] fs/ntfs3: Modified fix directory element type detection
6.1 02/28] fs/ntfs3: Improve ntfs_dir_count
6.1 03/28] fs/ntfs3: Correct hard links updating when dealing with DOS names
6.1 04/28] fs/ntfs3: Print warning while fixing hard links count
6.1 05/28] fs/ntfs3: Fix detected field-spanning write (size 8) of single field "le->name
6.1 06/28] fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame(
6.1 07/28] fs/ntfs3: Disable ATTR_LIST_ENTRY size check
6.1 08/28] fs/ntfs3: use non-movable memory for ntfs3 MFT buffer cache
6.1 09/28] fs/ntfs3: Prevent generic message "attempt to access beyond end of device"
6.1 10/28] fs/ntfs3: Correct function is_rst_area_valid
6.1 11/28] fs/ntfs3: Update inode->i_size after success write into compressed file
6.1 12/28] fs/ntfs3: Fix oob in ntfs_listxattr

If you believe something else is needed, mail Sasha.

@pavel

I chose another path, as I think the maintainer is the best judge here: https://lore.kernel.org/all/bdea4053-b978-489d-a4a2-927685eee4a8@leemhuis.info/