Problem with renames between long names an short names [Windows]

[Finomosec]

Hi,

I have seen this repetedly now.

I have a program which apparently writes files first as short-windows-style-filenames and then renames them to long (normal) filenames (or something similar happens internally).

Example:

• Create as: BIGWOR~1.MP3
• Rename to: Big World - Me Gusta.mp3

This confuses syncthing as for windows these two filenames are the same file.

But syncthing can not find the short filename anymore and the gets stuck with this (on another device):

Workaround:

• Move the stuck files out of the folder
• Sync
• Move them back
• Sync

Addition:

I just noticed syncthing creating this file on the sending device after I tried my workaround:
~syncthing~LU483C~1.MP3.tmp

I deleted it. Nothing bad seems to have happened.

[imsodin (Simon)]

I assume this occurs since watching for changes is enabled? Through that short filenames were introduced into the database, which confuses the heck out of Syncthing. This was fixed here: https://github.com/syncthing/syncthing/pull/4975. The broader issue is https://github.com/syncthing/syncthing/issues/3800, which has some similarity with the entire case (in-)sensitivity/forbidden names story (at the very least in the sense that it is highly annoying and cumbersome x) ).

[Finomosec]

if (pathExists && path.Contains("~"))
    path = this.GetLongPathName(path);

Nice

calmh added this to the v0.14.49 milestone 4 days ago

ok thanks!

[usernamegoeshere]

~ is a valid normal character for file folder names on windows. is the code changes working when the user has a short name containing that char ?

e.g.

> 26.03.2016  13:16             8.068 STI_TR~1.LOG Sti_Trace.log
> 03.03.2016  21:00    <DIR>                       Sync
> 11.06.2018  16:39    <DIR>                       test~1
> 17.03.2015  19:49    <DIR>                       Tracing

as being shown with dir /X

the “test~1” is a short name but has the char, there is no separate long name for it.

[imsodin (Simon)]

That depends on how the windows API reacts to being called on test~1. Best case it will just return test~1 without an error and we will use that. “Worst” case it will return an error, then we won’t scan just test~1, but its parent directory. Either way the result will be correct, it’s just more or less efficient.

[canton7 (Antony Male)]

It will be fine: the winapi returns test~1 as the full path. The edge case is when a file containing ~ is deleted: in that case the parent is scanned.