I have a console app build in 2022r4 for macOS. It works fine if you pass in a full path, but if you try to use a relative path, such as “…/foo/bar” it fails, with the exception:
UnsupportedFormatException: Passing non-absolute shell paths is not currently supported
To work around this, I create a fake path as follows:
// get current path for the current working directory
dim currentPath as string = GetFolderItem("").ShellPath + "/"
// try as absolute path first
dim f as FolderItem
try
f = new FolderItem(path1, FolderItem.PathModes.Shell )
catch ee as UnsupportedFormatException
// try as relative path
path1 = currentPath + path1
f = new FolderItem(path1, FolderItem.PathModes.Shell )
end try
This works fine. However I notice somethimg weird in the debugger, which is that the folderItem’s ShellPath includes the “…/” string:
I would have expected the FolderItem to parse the file properly to get the “true” path:
/Users/username/Documents/MyTool/test/file1.test
I can work around this easily by doing this:
f = f.parent.child(f.name)
My question is - what’s the “right” behavior? Should a folderItem created with one or more “…/” strings still have these strings in the path? Or should it be parsed to get the actual path?
How is this path resolved? Do the “…” move to the parent folder, like usual, even in the middle of a path?
If so, the path above would equal to:
/Users/username/Documents/MyTool/test/file1.test
(in other words, you’d just remove the folder before the “…” and the “…” itself). Or is it something else?
Yes, but please note it’s two periods, not three: “…” not “…” You can have more than one, and repeatedly go up and down, e.g. /Users/username/Documents/../Documents/../Documents/../Documents
and /Users/username/Documents/../../../
are both legal
As noted above, the workaround to resolve the path is to do this:
f = f.parent.child(f.name)
which is almost surely safer than trying to parse the path string yourself.
But the real question is whether Xojo should (or should not) be doing this resolution for you?
Yes, I wrote two periods in my reply. As you can see in your post, it’s the forum that converts two periods into three (you also have “…” twice, like me).
I’m guessing you could stumble on security restrictions with navigating using folderitems, which parsing could avoid.
E.g. in: /Folder 1/Folder 2/…/…/Folder 3
If you don’t have permissions to access “Folder 2” (or “Folder 1”), using child and parent methods, you’ll get an exception, while, with parsing and removing the folders when you find “…”, you avoid completely entering of “Folder 1” and “Folder 2”.
If there were security restrictions, you wouldn’t have the original folderitem in the first place. I agree with Mike that Parent.Child is the better approach. Or just not worry about it, because the path is technically correct.
True, but we are talking about paths. You can save a path once, then the user changes permissions and your app runs again, getting a path it can’t access anymore.
Is this true? It was my impression that you could always create a FolderItem to any arbitrary path (as long as the path was valid) regardless of permissions, and you would only get an exception if you tried to do something with that folderItem (such as writing to it, creating a new child, etc.)
.