One of my customers has opened a case because of Umlaut. However this defect (yes, it is a defect now)  is based on Filr Desktop client as far as I know (Umlaut in directory names). Solution maybe in 24.2 ...

So I went forward and setup a Windows 2019 <spit> server to test it myself in the lab, and what can I say? I can easily duplicate it. I really can't believe such a bug exists in 2024. :(

Looks like 24.1 fixes it.

Now we have to talk again about the ".4 is long term supported, and the others not" scheme, where you can't even stay on 23.4 if you say want to apply security fixes for the appliance. I think this whole versioning scheme wasn't thought thru.

Edit: Please see my next post. Not the case, the problem is still in 24.1

I spoke too soon. :( The problem is, the issue is timing sensitive, as it only happens on renames.
A rename occurs when you create a new file within windows explorer inside the filr folder. If you enter the real name of the file you created fast enough so that filr never syncs the initial "New filename", but only syncs the final name, then the issue doesn't occur.

I didn't test good enough. The issue still exists in 24.1

Much to my surprise, I just realized this issue also exists on OES23.4 NSS Network folders via NCP. :-O So it's actually not SMB.

I just checked this out of interest, and yes, the log you post suggests that it is not smb that's the issue.

The log shows it gets given the SMB URI "smb://srvad01/Testordner/Neues%20Textdokument.txt,smb://srvad01/Testordner/G%C3%83%C2%A4rtner12345.txt"
If you urldecode that you get "smb://srvad01/Testordner/Neues Textdokument.txt,smb://srvad01/Testordner/Gärtner12345.txt".

That is clearly a text that was written in UTF8 being read in ISO-3359-1, so a 16bit character being read in an 8bit encoding, and it happens before URL-encoding the path. We just did some test here with a Desktop Client 24.1 in DE and EN on Windows 10 vs. NSS-backed Net Folder, and we can confirm that the issue comes from Windows' "create+rename"-thing, because if you are really fast, then you can create a new folder with an Umlaut-name without garbling, and we guess that's because the create("Neuer Ordner")+rename("Neuer Ordner","X") gets collapsed to a single ReST request create("X").

HTH!

That is correct, it only happens on renames, and if you name a new file fast enough, there will only be a single "create" on the wire with the new name, and that works.
Same as copying existing files from external with Umlauts, that works too. But at the same time renaming existing files into something with an Umlaut also fails. Whenever you rename something in a Filr Desktop folder into something that contains a german Umlaut, it will garble the file or folder name.

Did I mention this happens in Macs too?

Yep, you did mention that. So it looks like there is an encoding gremlin somewhere inside the rename execution chain Listener(Client)->DesktopClientCode(python iirc)->ReSTCall->RestServlet. The latter could be checked if we manually fire a rename call over ReST, but "ain't nobody got time fo dat" on our side. I do hope this info makes it back to the devs. Is there an open SR for this? If not, I assume Robin may scan this thread when he comes back from the OPenText/TTP Developer Conference in Bangalore and feeds it back to where he just came from. Or he is actually scanning this and the devs already know about it :).

Yes, I have a SR, and there is a bug. But it's not moving in the speed I'd like, as this one is really a nasty one.

I guess it will get more attention next week, until tomorrow the devs are giving talks and getting input from partners and customers at the conference. It was plugged in several webinars and I unfortunately couldn't make it this year. I have been there and it is absolutely worth the trip if you can make the time.