1.11.6: Empty 0-byte file created and source file overwritten when copy-pasting via Ctrl+C/V on NAS

[madpainter]

XnView: MP 1.11.6 - 64 bit
OS: Windows 11 Home - 64 bit
When attempting to duplicate a file within the same directory on a network-attached storage (NAS) using Ctrl+C and Ctrl+V, XnView MP fails to generate a uniquely named copy (e.g., "_1"). Instead, it triggers a "Replace file" dialog. If the user accepts, the source file is instantly overwritten and reduced to a 0-byte corrupted file, resulting in data loss.
(Note: Copying via Ctrl + Drag-and-Drop works properly as a workaround and creates a duplicate safely.)
Effect: Files are deleted / overwritten with 0-byte files (Data Loss)
To reproduce:

1. Open a folder located on a NAS (network shared folder via UNC path).
2. Select any file (e.g., image.jpg) and press Ctrl + C.
3. Press Ctrl + V in the same folder to duplicate it.
4. XnView MP incorrectly prompts a "Replace file" dialog instead of automatically creating a renamed copy (like image_1.jpg).
5. Click "Replace" on the prompt.

Actual behaviour (bug): The original source file is overwritten, destroyed, and becomes a 0-byte file.
Expected behaviour: XnView MP should automatically detect that it is the same directory, auto-rename the pasted file (e.g., file_1.jpg), and copy the data safely without prompting a replacement dialog or destroying the source file.

[xnview]

are you able to reproduce it??

[madpainter]

>are you able to reproduce it??

YES
To reproduce:

1. Open a folder located on a NAS (network shared folder via UNC path).
2. Select any file (e.g., image.jpg) and press Ctrl + C.
3. Press Ctrl + V in the same folder to duplicate it.
4. XnView MP incorrectly prompts a "Replace file" dialog instead of automatically creating a renamed copy (like image_1.jpg).
5. Click "Replace" on the prompt.

Could you please try reproducing it by opening the NAS folder directly via its UNC path (\\...) instead of a mapped drive letter?

[madpainter]

2026-09-30 175011.png

Update:
I have updated to the latest version XnView MP 1.12.1 (64-bit), but the issue still persists.
As mentioned above, this critical bug occurs only when accessing the NAS via a direct UNC path (e.g., \\SERVER-S-MAIN\00alpha\TRASH\).
I confirmed that the bug happens even with a purely alphanumeric path and filename:
\\SERVER-S-MAIN\00alpha\TRASH\kari.jpg
If you test this using a mapped network drive letter (e.g., Z:\), it works fine. The bug is strictly triggered under the UNC path (\\...). Because it results in immediate data loss (overwriting the original file into a 0-byte file), I highly hope this can be investigated.
Please ensure to test by opening the folder directly via its UNC path.

[xnview]

I have updated to the latest version XnView MP 1.12.1 (64-bit), but the issue still persists.
As mentioned above, this critical bug occurs only when accessing the NAS via a direct UNC path (e.g., \\SERVER-S-MAIN\00alpha\TRASH\).
I confirmed that the bug happens even with a purely alphanumeric path and filename:
\\SERVER-S-MAIN\00alpha\TRASH\kari.jpg

I've tried and no problem here. In your screenshot, i see \\SERVER-S-MAIN & \\server-s-main

[madpainter]

Thank you for pointing that out. Yes, exactly! As you noticed in the screenshot, the coexistence of \\SERVER-S-MAIN and \\server-s-main within XnView MP is the exact root cause of this bug.

The reason you cannot reproduce it on your end is likely because XnView MP correctly normalizes the path to lowercase in your environment, preventing this string mismatch from ever happening.
In my environment, however, XnView MP's internal directory navigation or caching mechanism sometimes fails to normalize the path, leaving the address bar with the uppercase \\SERVER-S-MAIN while the file operation handles it as lowercase \\server-s-main.

When this specific mismatch state occurs:
1. XnView MP performs a case-sensitive string comparison on the paths during Ctrl+C/V.
2. Because SERVER-S-MAIN and server-s-main do not match exactly, XnView MP falsely assumes the destination is a different directory.
3. This triggers the "Replace" dialog instead of auto-renaming, leading to the 0-byte file corruption.

Suggested Fix:
Since changing the path comparison to case-insensitive globally might cause issues on case-sensitive OS/file systems (like Linux), the best solution would be to ensure that XnView MP strictly and consistently normalizes the case of UNC paths (server names) within its internal cache and address bar on Windows.
If XnView MP can guarantee that the server name is always kept in the same case (e.g., always converted to lowercase) throughout all navigation and history caching, this mismatch and the resulting data loss will be completely prevented.

[xnview]

In my environment, however, XnView MP's internal directory navigation or caching mechanism sometimes fails to normalize the path, leaving the address bar with the uppercase \\SERVER-S-MAIN while the file operation handles it as lowercase \\server-s-main.

Where do you have uppercase \\SERVER-S-MAIN?

[madpainter]

Thank you for your question. Please take a look at the attached screenshot, which clearly shows the issue.
As you can see in the screenshot, a discrepancy occurs simultaneously on the exact same screen:

2026-10-08 135623.png

• Window Title Bar (Top): \\SERVER-S-MAIN\00alpha\TRASH\ (Uppercase)
• Address Bar: \\server-s-main\00alpha\TRASH\ (Lowercase)
While it is difficult to reliably trigger the exact navigation steps that cause XnView MP to fall into this mismatched state, I have confirmed that whenever the screen is in this state, the Ctrl+C/V bug is 100% reproducible.
When this mismatch occurs, XnView MP apparently uses the uppercase version from the title/history context for one check, and the lowercase version for the actual file operation. Because the strings do not match exactly, XnView MP falsely assumes the destination is a different directory, prompting the "Replace" dialog and causing the 0-byte file corruption.
Rather than chasing down the exact navigation trigger, this proof shows that the internal string handling for UNC paths can become inconsistent. The safest fix would be to ensure that XnView MP strictly normalizes the case of UNC paths (ideally converting the server name to lowercase consistently) in both the title bar, address bar, and internal cache on Windows.

[xnview]

When this mismatch occurs, XnView MP apparently uses the uppercase version from the title/history context for one check, and the lowercase version for the actual file operation. Because the strings do not match exactly, XnView MP falsely assumes the destination is a different directory, prompting the "Replace" dialog and causing the 0-byte file corruption.

But from where is the uppercase path? When using path field or folder view or thumbnail view or..?