with slashes change

Up through at least Xojo 2019r1.1 the in macOS would contain a slash if it had one in the Finder name (yes, I know that internally it was replaced with a colon). Sometime between 2019r1.1 and Xojo 2019r3.1 this behavior changed. Now will use a colon to represent the slash. This means

“test/name.pdf” is represented by as “test:name.pdf”

This causes a problem for anyone who has stored file names using previous versions of Xojo (going back forever). Because now,

folderItem = SpecialFolder.Desktop.child(“test/name”) will no long find that file (even though you can see it there).

It will be found by SpecialFolder.Desktop.child(“test:name”), even though to the user there is no colon in the name.

In my case, where my users routinely store the names of thousands of PDFs, the stored names will no longer match the name that Xojo assigns to the file. For example, when my app looks in a folder for the file test/name.pdf it will come up empty, even though the file with that name is there.

I don’t want to get into a debate about how slashes and colons should be handled in macOS, I get it. The problem here is one of backward compatibility. This new naming convention will break a lot of existing code and in a very subtle way, since it only affects files whose names contain slashes.

folderItem.displayname does have the slashes, of course, but it’s unreliable because the displayname changes will be different if the extension is showing or not.

I’m posting this to let people who missed this know in case they’re finding otherwise unexplainable file problems with existing code. I’ve filed a Feedback requesting that the longtime behavior be restored, if anyone wants to sign on. I have no objection to having the folderItem contain a name in which the slash is replaced, but for backward compatibility I suggest a new property be added, something like folderItem.truename, rather than changing the long-established behavior.


Are-you able to create an item in your Finder (your macOS running version) ?

Last tie I read the Apple documentation, it was said that the : is a path delimiter.

I know things are running strange nowadays @ Apple, but a change like that is a break in the use of items (imagine a user will move that file nto an older macOS version ? (it will be either rejected at copy time or the : will be changed to a - as it may be on old macOS versions…

I’m not talking about the pathname (where for historical reasons Apple indeed uses a colon instead of a slash), I’m talking about the name of the file itself. No, you can’t create files in the Finder with a colon. File names with slashes have always been allowed in macOS, are of course still are. But now Xojo represents them with a colon, which is just wrong. And, as I pointed out, breaks existing code.

OK, I understand now.

Siple addition:
Firefox strips the / given in the file name at save time (images, not checked the html file names I think). I saved some Singles Beatles Covers with “b/w” in the file name and they wzre stripped by firefox. And as you already said, when I added them in the Finder, they were accepted.



Yes, since Xojo v.??? if a FolderItem is named with a slash (“gh/kl”) you will obtain in Xojo MyFolderItem.Name -> “gh:kl”.
In the SaveFileDialog, the SuggestedFileName automatically replace the “:” by a “/”.
But if we want to display the name in a ListBox, we have to MyListBox.AddRow MyFolderItem.Name.ReplaceAll(":", “/”).
And if the user edit the CellBox and we want to rename the FolderItem then we have to do :
MyFolderItem.Name = MyListBox.Cell(x,x).ReplaceAll("/", “:”)

I suppose that, since Mac OS system doesn’t use AbsoluthPath (separated by colon “:”) anymore but now use NativePath separated by slash “/” they had to do some change.
I don’t use Xcode, I ask myself what return the Xcode instruction when read a name of a file containing a slash “/” in its name.

But that’s the wrong behavior. I’m talking about FILE names not pathnames. File names can contain slashes, it’s perfectly legal in macOS. As I said, macOS hasn’t changed and Xojo has used slashes in safely since it was created. But now Xojo refuses the legal slash in the file name. This is the problem as I’ve been trying to explain. It seems to have been confirmed as a bug in the Feedback report.

I think I well understood, but as the path wre AbsoluthPath separated by : and now are separated by / , we can’t keep / in a name.
MyDisk.Name = “Disque1” with a folder inside “Folder-A” which contains a file “File/Bg”.
The AbsoluthPath is “Disque1:Folder-A:File/Bg”
but the NativePath would be “Disque1/Folder-A/File/Bg” then with a file “Bg” in a folder “File” that’s why I suppose that the
NativePath is “Disque1:Folder-A:File:Bg” (each name of disk, folder and subfolder and file with / replaced by : )

AbsolutePath works just fine in macOS (with colons). It was deprecated in Xojo, that’s all. You can still use them with MBS plugins, for example.

I’ll say this for the last time. I’m not talking about pathnames. Slashes are perfectly LEGAL in macOS file names. Try naming a file “my/file” in the Finder. No problem. That is its name, and macOS is smart enough to know that the slash is NOT a directory separator, it’s part of a name. Xojo has always left the name alone, which is correct.

Xojo had correct pathnames through 2019R1.1. In 2019r1.1 these are the relevant folderItem properties for the file “File/Bg” = File/Bg.pdf
f.nativePath = /Users/jon/Desktop/File:Bg.pdf

The new change in (which in 2019r3.1 is File:Bg) is the bug, and will prevent you from opening that file if you reference it by name the user gave it and which you see in the Finder, File/Bg.pdf.

FWIW, the change we made was to update the underlying macOS API that was being used for FolderItems, so it’s possible that the behavior change was actually there as opposed to our framework.

I renamed an excel file to “test/test.xlsx”, Excel doesn’t have problems opening the file but the Excel window shows the name as test:test

Saving changes to the same file is not a problem, but if I select Save As and instead of the suggested name of test/test.xlsx I use test/test1.xlsx I always get an error that says: “You do not have permission to save files to this location.”

What I’m trying to say is, if Excel can open a file with such a name may be Xojo can try to make it open too, even when saving with a different name containing a “/” should not be allowed (if we follow Excel’s behavior).

There are at least two major problems with the change in the way the folderItem name is now rendered if you want to display it or store it in a database. (1) any name stored using older versions of Xojo will fail. Simply put, looking for “text/text.xlsx” will fail, even though that file exists, and (2) the name your app would display (“test:test.xlsx”) would not match what the user can plainly see is there. The first is the major problem, because it breaks existing code. I have thousands of users with thousands of names stored in their databases (mostly PDF names), and upgrading to 2019r3.1 or beyond would break this function. The workarounds are not trivial and, in fact should not be necessary. @Greg O’Lone I hope Xojo can restore the previous behavior so that actually uses the name we see in the UI.

The FInder accepts the slash. But if you create such an item and then go into Terminal, then by listing the files you will find that the file now has a colon in its name rather than the slash that the Finder shows (I just did this in Mojave). Further, the Finder does not accept a name with a colon in it. The macOS pathname separator is the slash.

That’s because Terminal is a UNIX utility, and in UNIX the slash is used to separate directories. macOS has always used a colon internally (and still does AFAIK). Please see my comment just before yours. There is nothing that prevents Xojo from restoring its own behavior with regard to displaying the slash in the and resolving it when using folderItem to open a file. That restores the behavior that has existed since forever and solves both problems. As it stands, if you use a folderItem to open a file whose name (not pathname) contains slashes, it will fail and tell you that file doesn’t exist. Do you see the problem? There are workarounds, as I said, but they are tedious and more like applying a bandaid. One of the simpler workarounds would be to extend, but that doesn’t seem to be possible.

I think you’re getting this back-to-front. The slash-to-colon change is done by the Finder. macOS itself, as a unix system, uses the slash as directory separator and won’t allow a slash in a filename. So the FInder converts that to a colon when dealing with the underlying file system.

macOS isn’t pure UNIX, and historically the colon is the directory separator (which is why you can’t use a colon in a filename – try it).

link text

That’s from 2017. If you have more recent information to the contrary I’d like to see it. Greg would know.

In any case, this is all beside the point. I’ve outlined the problems with the new behavior and that it breaks existing code. How Xojo handles the file name is an internal matter, and they can continue to show the name with a slash, as they always did, and then resolve it to whatever is required to match the actual file in the Finder when they interact with the Finder APIs.

The behaviour in Xojo is according to the current API from macOS. I remember having problems with slashes and colons, too. For me it was a colon in a name of a mailbox that is translated to a slash in the Mail folder. I had to take out some replacement code as far as I remember.

Allowing slashes and colons in any file name is a bad idea. Always has been.

Nonetheless, slashes are allowed in macOS file names and always have been. I’ve outlined the problem, Xojo recognizes it in the Feedback, and now it’s up to them to decide if they want to institute an internal fix or not.

After seeing Excel having problems with names with slashes, I did a test with Pages. The result: no problems at all. I can save a new file with a slash in it, open the file, save to other locations, etc.

So I think Xojo should try to work just like Pages and not have problems like Excel.

I disagree; macOS is pure unix for the purposes of this discussion (as far as I know) with the Finder allowing slash to be converted back and forth to a colon for the unix file system layer. And I mentioned that you can’t use a colon in my post before last.

I’m not sure why Apple bothered to do that, except that the colon was the directory separator under Classic Mac OS in the 80s and 90s.

Anyway: that’s me done.