I agree.
As I see it, escaped characters aren’t the problem here. Escaped characters are just a representation of a string, while the problem here is the correct value isn’t even retrieved by the API call(s).
If you get just the last part of a slash-delimited file name from a given API, you can hardly transform that into an escaped-characters correct version.
Are you saying that it not a Xojo problem? An update of the OS changed the behavior?
You are using Windows, don’t you? Because “/” are forbidden in Unix filenames.
I don’t fully know what the problem is, but this issue apparently comes from the switch Xojo made, using newer API calls.
Now, I fail to see how Xojo could be at fault, since it would just obtain a file system attribute (the name of a file system object) which it has no reason to “convert”.
I don’t think it is OS API related, but related to Xojo refactorings.
I’m sure this was discussed on the Testers channel. A newer set of Apple APIs is now in use, another side-effect of which is that when you ask for the directory contents, it no longer comes back in alphabetical order.
I don’t know if you referred to me, but no, I use mainly Mac OS X.
“/” are also forbidden on Windows, along with a long list of other characters. It’s harder to name files there… 
On Mac, you can actually have a file name that contains slashes; just make a new folder and name it “My/test” and it’ll work.
The OS type is irrelevant here. You may be running Windows with an AFP share, thus be allowing to use file names such as “What’s this file?.txt”. Or be on MacOS with a SMB share and be limited to Windows’ allowed characters.
The file system is the relevant part, but what’s a “Unix file system” anyway?
HFS+, APFS and ext4 may be considered “Unix file systems” since they are used on operating systems based on Unix, but they are still different.
Right. I forgot this is new to users not in this channel.
Thanks for pointing this out; I didn’t realise it wasn’t known in the wild.
I think you’re mixing things here. The “unspecified” order problem comes from the APFS implementation. I think, even with the newer API calls, that you’d still get items sorted alphabetically on HFS+ volumes.
I don’t say it’s not possible, but how would Xojo fail at returning a string it just obtained with an API call?
It was discussed in the Testers forum (with nothing helpful being posted), but since then Xojo seems to have made changes (perhaps in an attempt to fix the problem) which have made some things worse in the final Xojo 2020r1 release. See the Feedback report with this new information and a small project that I linked to in my first post here. No doubt the problem was introduced by switching APIs, but that doesn’t mean it can’t be fixed.
That’s entirely possible 
That the issue is not known to non-Testers highlights something that Xojo (IMO) overlooked in the Release Notes: a section which could note the API changes (if any) and list anything that could e a potential problem, such as this one and also the issue I had in the HTMLViewer. After all, these are things that the testing threw up.
This was discussed in public a few weeks ago:
Some filesystem that follows the Unix FHS. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
Totally agreed.
That wouldn’t be a problem on its own; just replace “:” by “/” or the other way around to have either.
In this thread, it’s about the name being shortened. The behaviour is different (and not so easily recoverable) but you’ve perhaps found the cause, indeed.
Please refer to the Feedback report mentioned in first post of this thread. There is also new problem with slashes, and colons are not involved. To whit, in 2020r1 if you refer to a file with slashes in the name
dim f as FolderItem = SpecialFolder.Desktop.child(“this/is/a/test.pdf”)
Xojo will report that
f.name = test.pdf
For what it’s worth I have a similar issue to Jonathan but in my case it’s slashes in a folder name (running Xojo 2020r1.2). If I create a FolderItem of a file and the path has a directory with a slash you have no way to Split the path if you want to get the dir names, splitting on ‘/’ will also split on the slash in the folder, making it appear as two folders when it’s actually one. Sounds like this wasn’t an issue in earlier versions as Xojo would show the name with the colon in the FolderItem same as running ‘ls’ or ‘pwd’ from the terminal. So now I can’t simply call Split() I need to find some other way to determine which macOS slashes are separating actual directories and which are part of the name which is impossible. I guess I could take the path and make a shell call to do an ‘ls’ but that’s excessive.
I may be wrong, but since when a Slash defines a directory (in a path) under macOS ?
Something like this would work:
dim f1,f2 as folderitem
dim Folders() as string
f1=SomeFolderItem
f2=f1
do
if f2=nil then exit 'Either f1 is nil or we have finished
Folders.AddAt 0,f2.Name
f2=f2.parent
loop