Created attachment 870942 [details]
chkdsk log

I use a dual boot system with openSuSE Tumbleweed and the latest Windows 10 with a shared NTFS data partition.
In summer 2022, I replaced the FUSE driver ntfs-3g, which I had been using for about 10 years, with the kernel driver ntfs3. After renaming images with the digikam programme, many images had disappeared. Under Windows I realised that the file system was defective. After the repair, the disappeared pictures were back with their new names. I changed the driver back to ntfs-3g.

On 07 June 22 and 09 June 22 I informed Paragon about this problem via the contact form and in detail via e-mail. I ruled out the digikam programme as the cause of the problem and informed them that the file system is also damaged when renaming with a shell script.

To prevent my file partition from becoming too damaged, I created a 10 GB VHD under Windows with the NTFS file system for testing. I filled this with files (images and videos) and ejected it. 
The VHD was mounted in a virtual machine (VirtualBox) with Tumbleweed.
/etc/fstab: UUID=6E649E38649E034F /pictures ntfs3 users,uid=hds,gid=users,fmask=133,dmask=022,windows_names,discard 0 0

In a directory, 510 of the 573 files are to be renamed based on their name in a FOR loop.
After renaming, only 17 of the 510 renamed files were visible.

Under Windows, the file system could be repaired and all disappeared files were available again with their new names. 
This behaviour is reproducible from kernel 5.18.1-1-default to kernel 6.5.9-1-default. 

Rename script:
#!/bin/bash
i=1
for f in 2020_Garten_Sommer*.jpg; do
  echo mv $f new_name_$i.jpg
  mv $f new_name_$i.jpg
  let "i++"
done