1.5.3: Crash when renaming multiple files

[cyberfuzzie]

XnView: MP 1.5.3 - 64 bit
OS: Windows 10 64bit

When renaming multiple files (batch rename), sometimes XnView crashes.

Effect:
Some of the files are already with the correct name, whereas others are renamed to tmp-xnview-<number>-<oldname>.

To reproduce:
1. Select multiple files in a folder
2. Press F2
3. Choose a pattern. Usually I skip this step because the previously used pattern is already ok. I'm using ###-{Filename[5-]}
4. Press OK (assuming the last used pattern is appropriate)
Unfortunately, this does not always reproduce the behavior. Sometimes, it crashes rather frequently, then again it works for a long time without issues.
It might work to just select some files (100 or so, sometimes also happens with fewer images), and then repeatedly press <F2><Enter><Enter>, which will just rename the files to the same names again and again.

Actual behaviour (bug): Sometimes, XnView crashes during rename

Expected behaviour: Files are *reliably* renamed

Edit: I've also now uploaded a sent a crash dump for this problem.
It might have to do with the speed of the drive where the folder is located on. When trying on the internal SSD, I was unable to reproduce it. Repeating it with the same images copied to an external USB HDD, the crash did appear again.

[xnview]

I don't see your crash dump, could you send it again, and add the thread url

[cyberfuzzie]

That's what I did the first time, I've sent it again.
You can also download it from here: https://drive.google.com/file/d/1NvMFDg ... sp=sharing

[xnview]

That's what I did the first time, I've sent it again.
You can also download it from here: https://drive.google.com/file/d/1NvMFDg ... sp=sharing

Ok, thanks. Could you send me your xnview.ini too? how many files do you rename? JPEG files? with sidecar?

[cyberfuzzie]

I tried with a fresh configuration, i.e. remove xnview.ini and try to reproduce the bug. It still crashed.
You can find the xnview.ini here:
https://drive.google.com/file/d/1uO53Jf ... sp=sharing
(I closed XnViewMP once normally so that the .ini was written, otherwise it would be a 1.5kb file)

The example folder I used consisted of 117 jpg files, 2000x3000 pixels each, around 57MB in total.
A sidecar is a .xmp file next to the images? I don't have that.

I've also managed to reproduce it with 30 images, which were all copies of the same image; random noise generated with gimp.
Here is the example image, I simply created 30 copies of it:
https://drive.google.com/file/d/1BDyKbm ... sp=sharing

[xnview]

i've tried with your ini or a fresh one, and can't reproduce the crash. If you use ###-{Filename}, same crash?

[cyberfuzzie]

Yes, same crash with ###-{Filename}, and also with ###

I suspect it is something specific to the drive I'm using.
* Internal SSD: no issues
* External (USB3) HDD: crash, usually within 20-30 tries
* External USB Stick (very slow): no issues
Probably some specific timing leads to a race condition or similar.

I've also monitored xnview with process monitor and found something, which may be connected:
Right before the crash dump is created, there is a NotifyChangeDirectory operation with flags FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME with result CANCELLED. This specific combination does never occur, when there is no crash.
This leads me to the following speculation:
* At some point, xnview registers for notifications when the files in the current directory are changed
* During the batch rename, that notification is repeatedly triggered
* For some reason, it can happen that the notification is cancelled
* Maybe due to incomplete error handling, some windows function is then called when it should not, causing the crash.
You can find the process monitor log files here:
https://drive.google.com/file/d/1YqkSUv ... sp=sharing
https://drive.google.com/file/d/1AeF7X4 ... sp=sharing

Please let me know if I can help you with further debugging, however, I'm now away for a week.

[xnview]

i send you a PM

[neeqkowlah]

I notice the same problem on linux if the files to rename are on a network connected disk
verion MP 1.5.5 64bits

[xnview]

I notice the same problem on linux if the files to rename are on a network connected disk
verion MP 1.5.5 64bits

you can reproduce the crash on batch renaming when source files are on network disk? and not on internal disks?

[xnview]

I tried with a fresh configuration, i.e. remove xnview.ini and try to reproduce the bug. It still crashed.

Do you have sent a crash dump with crash dialog (1.6.2)?

[cyberfuzzie]

I've sent a crash dump from 1.6.2 with the crash dialog now.
It is also available here: https://drive.google.com/file/d/150K1La ... sp=sharing
And this time the debug console stayed open, its contents are available here: https://drive.google.com/file/d/1ivmCeP ... sp=sharing

[xnview]

i've reproduced the crash only once i've sent you a PM