Accomodate Microsoft bug of inconsistency of allowable characters in file names

[cliquesoft]

I am attempting to sync two Windows computers and have run into several problems. I was informed to update to the latest CI version of unison. Upon doing so, I ran into this problem:

[ERROR] Skipping Common/OLD_E/Proposals/2019 Proposals/Name & Name Properties/Name at Name Lake Apartments/Bid Instructions, Schedules, and Misc. The name of this Unix file is not allowed under Windows. (File 'Common/OLD_E/Proposals/2019 Proposals/Name & Name Properties/Name at Name Lake Apartments/Bid Instructions, Schedules, and Misc.')

I suspect it is an issue with the '&' sign as that is a special character in Linux/Unix, but not in Windows.

Unison Info: unison-f215b64e.ocaml-4.11.1.windows-latest

Unison "Client" Config:

Unison preferences file - custom

root = D:
root = socket://Server:2299/D:/

Paths to include in the sync

path = Common\OLD_E

Optional parameters to use

fastcheck = true batch = true

Unison "Server" Started: "C:\Program Files\Unison\unison.exe" -socket 2299

Server Info: Server1 is Windows 2012 Essentials Server2 is Windows 2019 Essentials Both are using NTFS file systems Attempted to sync ~87GB of data

[gdt]

As I understand it, unison makes a design choice to restrict allowable file names to those that are ok on all systems. Perhaps you can find that in the docs, and/or fine a reference to POSIX about allowable characters in file names. I get it that this isn't what you want, but I am having a hard time saying what the bug is.

[tleedjarv]

As I understand it, unison makes a design choice to restrict allowable file names to those that are ok on all systems.

Yes, but Unison looks at the actual OS of each replica. Since this sync is between two Windows systems then POSIX rules are not an issue.

I've investigated and '&' is not the culprit here.

The error is raised because the name ends with a period (.). According to https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file (which Unison adheres to), this is sort of not allowed, but may still be supported on some file systems (NTFS?).

I don't know if a fix is required here or not. Unison does adhere to Microsoft's naming conventions. At the same time, @cliquesoft has managed to create such a name and I assume is not experiencing any other issues because of it. Unison doesn't know the underlying filesystem, so it is not easy to check for NTFS, for example. An acceptable way could be to allow this name in Unison. If the filesystem does not support it then the syscall will return an error.

[gdt]

I'm going to say that Windows documents that these filename are not allowed, so this isn't a Unison bug.

I'm willing to look at a PR that does someting like @tleedjarv suggests, trying it anyway, as long as we have reasonable behavior when the syscall fails.

[gdt]

Feedback timeout. Feel free to file a new issue with a repro recipe with 2.53.1 or newer.