Error: The path passed into new FolderItem was invalid

In the last ~6 months (on Yosemite and now El Capitan) I’ve had a few dozen reports of problems opening files that are on the HD, the error message being:

 error The path passed into new FolderItem was invalid

I cannot reproduce this problem. In the latest example, this is the code that I think gave the error:

 f = GetOpenFolderItem("text;xml")

This works 99.9% of the time, but in some cases gives this error. I’ve suggested that the users reboot or relaunch the Finder, which seems to fix it (at least they don’t get back to me with more problems).

This code has worked without problem for as long as I can remember, but recently has resulted in this intermittent problem. Any idea of what’s going on?

you have a file named that on OS X ?
Specifically mentions ;

It’s not my file, it’s dozens of different files from dozens of different users (it’s a commercial application, I’m getting error traces automatically sent to me). These are legitimate Mac file names AFAIK. I’ll try to have one sent to me, but since rebooting seems to take care of it I doubt I’ll see anything unusual.

Commercial / free / share ware / wrote it for my mom … doesn’t really matter so isn’t relevant

That they have such odd file names is peculiar and some file systems might give you grief about them

Renaming the file might work quicker than rebooting

It matters in that you wrote " you have a file". I don’t, my users do. With so many reports of this I very much doubt that any of these files has illegal characters. And if they did, why would rebooting make any difference – illegal is illegal?

However, I’ve written to some who have reported this to obtain the files and we’ll see. Since this isn’t ringing a bell with anyone, I’ll have to hope I can reproduce it.

Hm, I didn’t fully understand your initial reply (why mention ; ?), but perhaps you were referring to my code

f = GetOpenFolderItem(“text;xml”)

If so, those are the Xojo file types I’m screening for (and are defined as distinct file types in my project). Are you saying I’m doing that incorrectly?

BTW, I created a file with a ; in the name and Xojo handled it without a problem.

What makes you think this is the offending line?

I’m not able to generate that error message with GetOpenFolderItem but with new Folderitem the message comes in an UnsupportedFormatEcxeption.

dim f As Folderitem = new Folderitem("|:;'/|:}")

Because I have a stack trace, and I know (in one instance, at least) that the user was opening an XML file. And this is the line where that would occur.

In your example, you have a /, which is not allowed in OS X. But we’re getting far afield. The error is “The path passed into new FolderItem was invalid”. I suspect that’s not from Xojo, but would be interested to hear if I’m mistaken.

Yeah, I’m just showing that this will cause the error message you’re seeing and thought maybe you have a “new Folderitem” somewhere because I can’t get GetOpenFolderitem(garbage) to exception.

getting the user to locate the file in the finder / explorer and copying the path to send to you would be useful

I also got the same error, one of my programs search preference information in a folder and sometimes it seems that the path does not exist, then I give restart the Mac and when he returns to work everything is ok, do not worry much even for now is sporadic as it does not interfere in the normal work, but it is very strange problem.

Actually, that error is mentioned in several posts throughout the old and present forums."The+path+passed+into+new+FolderItem+was+invalid""The+path+passed+into+new+FolderItem+was+invalid"
But the posts up until now always mentioned it for GetFolderItem(), not GetOpenFolderItem. So this is new.

I have no idea how GetOpenFolderItem is actually coded, but if it first calls the file picker and then turns to GetFolderItem to create the actual object, then it would make sense. Now since the issue resolves itself with a restart, I would be tempted to suspect a random Cocoa bug.

I tried to search the Apple forums, but the haystack was uncooperative.

I have more information about this. It looks like a Xojo bug to me, but perhaps there is some internal logic to the way it is behaving that escapes me.

s = “/Users/validfolder/Documents/fileDoesNotExist”
f = new FolderItem(s, FolderItem.PathTypeNative)

returns a folderItem (f) where .exists = false. This is what I would expect.

But if I point to an invalid folder (rather than a file) like this

s = “/Users/folderDoesNotExists/Documents/fileDoesNotExist”
f = new FolderItem(s, FolderItem.PathTypeNative)

I get a UnsupportedFormatException error with the message: “The path passed into new FolderItem was invalid”

To me the path passed was entirely valid, it just didn’t point to an existing item.

And the reason I think this is a bug is that if I don’t specify FolderItem.PathTypeNative, I get no error.

s = “/Users/folderDoesNotExists/Documents/fileDoesNotExist”
f = new FolderItem(s)

I get a non-nil folderItem to a file that does not exist.

Norman, the behavior is inconsistent and strikes me as a bug…agree or not?

A FolderItem can only represent one level of non-existence, which is why you get the exception.

In the case where you don’t pass FolderItem.PathTypeNative, you’re actually getting a very different FolderItem than what you expect. It’s being interpreted as an HFS path.

I guess can see why the exception might occur.

The analogy I can think of is that if I specify f.child(“doesnotexist”) I get a valid folderItem that does not exist, but if I specify f.child(“doesnotexist”).child(“doesnotexist”) I get a NOE (the first child evaluates to nil, so the second yields the exception).

But in my case I would not expect a UnsupportedFormatException to be thrown (which confused the heck out of me, since I kept thinking there was something wrong with the way the file path was represented). I would have expected Xojo to take care of the problem and deal with it by providing a folder item where .exists = false. Or at least a NOE, which would seem to be closer to the mark.

Now that I understand it I can of course deal with it by wrapping these calls in try…catch blocks.

Thanks for the explanation, Joe.

From the FolderItem.Constructor doc page:

I read the section on folderitem multiple times but didn’t make note of this (in my defense, there is a lot of info there). Thank’s for pointing it out.

I was actually going to the doc page to add this info and I saw I already had added it (back in 2013)!