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 at 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.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171227/58098153/attachment.html>