I have not thoroughly investigated this, but this could be a case for the FileSystem API that Pharo has adopted as the default file accessing API. You do not pass file names around there, but references that are (path + the FileSystem in which they resolve). That way, the information that the gif lives remotely is not lost. Each FileSystem is then responsible for file name conversion and encoding if required.

Am 26.12.2017 22:15 schrieb "tim Rowledge" <tim@rowledge.org>:
… which leads me to note that ServerDirectory/RemoteFileStream seem to need some love, and it would be nice to integrate them better wrt file name stuff.

See ServerDirectory class>>#defaultStemUrl, for example - I’m fairly sure disney wouldn’t want us trying to save Books on ‘jumbo’ any more.

Consider that whilst FileList tries to handle remote directories, it fails horribly if you try to look at, say, a gif file on a remote server because the code asks for the full name of the file (rowledge.org//tag-comment.gif for example) and passes that to Form fromFileNamed: Since our filename handling stinks, it doesn’t work out that it needs to make a remote file stream etc.   It really is way past time we had a decent file name handling system that can sensibly deal with stuff like that, and the need to (often) convert file name related strings to/from UTF-8 when talking to a VM, and so on and so forth.
Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights