Cannot receive files with characters not allowed on Windows

[Alphastaire]

Windows file names cannot contain certain characters: \/:*?"<>|
Files with these characters sent to users on Windows fail to transfer.

In order for Windows users to be able to receive these files, the file names must be sanitized when saved by Dino+ to local storage.

[mxlgv]

@Alphastaire To be honest, it is not entirely clear how to fix this gracefully. Because it rather depends not on the OS, but on the file system. Yes, you can really check the file name for Windows for prohibited symbols, and for a prohibited name like "con" (a wonderful legacy of MSDOS). But it would be great if the file system itself said that "a file with such a name cannot be saved." In general, the second option is preferable. After handling such an exception, a new file name can be generated.

[Alphastaire]

@Alphastaire To be honest, it is not entirely clear how to fix this gracefully. Because it rather depends not on the OS, but on the file system. Yes, you can really check the file name for Windows for prohibited symbols, and for a prohibited name like "con" (a wonderful legacy of MSDOS). But it would be great if the file system itself said that "a file with such a name cannot be saved." In general, the second option is preferable. After handling such an exception, a new file name can be generated.

Yeah... it's not exactly the most graceful solution. I'm not fond of it myself. It's ugly. It's just the most common solution that I see other clients such as Gajim implement. I do agree something like that second option would be better, as it could notify the user of the file's original name. Gajim does some very aggressive automatic file name stripping (completely cutting off a file name if it encounters a prohibited symbol), which isn't very nice in my experience. My friend is constantly sending me images with such file names, and he has to tell me what they're originally named if we're using Gajim.

[Alphastaire]

My thought for a comprehensive solution: internally save received files to local storage using an entirely different file name (the checksum for example, which could also allow for deduplication if that's desired), while still displaying the intended file name to the user.

EDIT: Nevermind, deduplication is a bit too much feature creep for this issue. Maybe later.

[mxlgv]

@Alphastaire I thought that I could do this using an exception, but if the file cannot be created, EIO is returned, which can mean a lot of things.
Apparently for Windows we will have to do as you say, I will gladly accept this change.