File copy with long and short name bug from NT 4 still exists

[Tripredacus]

It seems that a file copy bug from the Windows NT 4 days still exists in Windows 10.

When you copy files from a source that uses both short file names and long file names, files may be lost.

This problem can occur when you perform the copy operation by using any of the following programs:

COPY

XCOPY

Windows NT Explorer

Windows NT Backup

This problem happens when a file that has a long file name is copied and a new short file name is generated for the file in the destination folder. If a file exists in the source folder and it has a name matching the newly generated short file name, this file will replace the first file and the content of the first file is lost.

KB source: https://support.microsoft.com/en-us/kb/195144

Better write-up with example regarding this behaviour with Robocopy from Wikipedia:Talk: https://en.wikipedia.org/wiki/Talk%3ARobocopy#More_details.2C_please.2C_on_.22Robocopy_doesn.27t_reliably_copy_short_filenames..22

A user finding this issue with Windows 10:

https://social.technet.microsoft.com/Forums/en-US/f72f82bb-7131-461e-b766-e5b401598a4d/file-explorer-loses-files-and-overwrites-wrong-files-when-copying?forum=win10itprogeneral

Seems to be an odd thing that was fixed for NT4, 2000 and Win95 but (presumably) no OSes after that.

[dencorso]

Does it happen regardless of filesystem or is it a NTFS-only issue?

 

BTW, xxcopy makes sure to copy both long and short names and to keep them synchronized.

[vinifera]

i guess it belongs to those bugs, if nobody notices it then its not worth fixing