Files with / in their name: folderitem vs. xojo.io.folderitem

macOS HS, xojo 2019r1.
On my desktop is a file called ‘2018/9 wiggy.jpg’.

If I run this:

[code]Dim fname, fpath as string, fh as FolderItem, fhx As Xojo.IO.FolderItem

fname = “2018/9 wiggy.jpg”
fpath = “/Users/tim/Desktop”

fh = GetFolderItem (fpath, FolderItem.PathTypeNative)
fh = fh.Child (fname)

fhx = new Xojo.IO.FolderItem (fpath.ToText, false)
fhx = fhx.Child (fname.ToText)
[/code]

then examining fh and fhx in the debugger as the code finishes gives this:

fh.exists is true, but fhx.exists is false
fh.name is ‘2018:9 wiggy.jpg’ but fhx.name is ‘9 wiggy.jpg’

Is this expected behaviour or a bug? Or is it moot anyway now due to API 2.0?

Looks expected behaviour, because the slash is used as a path delimiter.

Please compare:

fname = "2018/9 wiggy.jpg" fpath = "/Users/tim/Desktop"

Why not replacing the “/” character with an underscore “_”?

I’m not posting because I have a problem with the “/” in the name. I’m posting because under macOS the two FolderItem options provided by Xojo behave differently when there is a “/” in the name.

You should avoid using path separators in filenames (: or /). See
https://superuser.com/questions/204287/what-characters-are-forbidden-in-os-x-filenames

Sure. But end user won’t do that always. So we need to deal with possible filenames containing / (at least according to what the user entered and sees in Finder) on macOS.

So sooner or later we end up in a situation with: fileName = "2018/9 wiggy.jpg"
Now - using the “classic” FolderItem: aFolder.Child(fileName) -> works just fine and as expected.
Those that are using the “new Framework” Xojo. IO .FolderItem: aFolder.Child(fileName) -> won’t get you the file.

Neither is right or wrong. But .Child() behaves fundamentically different in the two implementations.
That’s what this is all about. FolderItem.Child seems to use the “file name such as the user sees it”, whereas Xojo. IO .FolderItem seems to use the “native/shell filename”. And they are different in this case.
So any code code ported to/from FolderItem <-> Xojo. IO .FolderItem won’t work in this situation.

I for one would like to have the same default behavior. And maybe it would be best to have a new FolderItem.Child(name As String, PathType As Integer). So we could explicitly declare what “naming convention” should be used. That would require someone to create a Feature request on Feedback.

FireFox removes the ‘/’ from the file name…

MacOS sometimes translate the ‘:’ to (I forgot what), sometimes (in the Fidner) reject the file name with a ‘:’ in it.

Your point is valid. Count on naive users to find creative ways of messing with your program.

I know this is not the most elegant, but you could rename the file while you are using it so it does not throw out FolderItems, and put back the offending characters when you are finished.

You could even warn the user that these characters may pose problems.

what i do in my application is sanitize the image name if it going to copy to another folder just for images… so my application will remove all the weird characters that will cause problem.

if it some links to open the original file in my application, i give an error message to ask them to change the name of the file and try again…

Under MacOS, do not add a trailing space (a space at the end of the folder name) and move the folder to Windows. Someone told me not to do that (apparently, Windows does not like it !).

In my opinion, expressed politely, you should never ever allow illegal file names onto your machine. You are just asking for trouble, and so it has been since the flood. Win NTFS rules are here:

https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file

I have seen one program - EAC - that created files with leading spaces in the names ( my error of name configuration ). The easiest way to fix was to copy the file in the file manager to another folder, and Win thankfully dropped the leading spaces.

what about leading space??

It’s not my machine; it’s the user’s machine.