getEntries() throws an error if the folder has user-assigned custom icon on Mac

Adobe XD UXP Plugin API
1

I’ve noticed that folder.getEntries() throws an error if the folder contains invisible OSX items, as when folders have custom icons assigned.

This folder has a custom icon (cmd + shift + . to show/hide hidden items):

Screenshot 2019-12-12 at 11.39.08
Screenshot 2019-12-12 at 11.39.08668×608 69.6 KB

The error is:
Error: no such file or directory] code: -2

This folder has the default icon:

Screenshot 2019-12-12 at 11.55.54
Screenshot 2019-12-12 at 11.55.54690×618 87.3 KB

In this case, folder.getEntries() is executed correctly.

OSX version: Catalina 10.15.1

2

Hmm. I’m wondering if this is an expected behavior. I will reach out to XD engineering (@schenglooi) to get an answer for you.

3

Thanks a lot @stevekwak!

4

I’ve notified @kerrishotts instead since this is a UXP bug. She did confirm that it’s a bug and she will create a ticket for this.

2 Likes
5

Any news regarding the above issue?
XD 27 keeps throwing that error.

6

Is there any chance that this will be solved in the next release?

7

We’re working on optimizations and a refactor in this area, so I’m hopeful this will be addressed. It won’t make it for XD 28, though. (TBD on when.)

1 Like
8

For what it’s worth: the only case we’re aware of where this is a problem is when the folder has a user-assigned custom icon. Other types of “hidden files” don’t cause problems as far as I know.

9

Confirmed, getEntries() throws the error with custom icons only. Hope it will solved soon, Mac users do love use custom icons.

10

This issue (or a variation) earned me a rejection from the review process. :slight_smile:

I’m not 100% sure that an Icon? file was present in the reviewer’s destination folder. I’ll try to confirm tomorrow.

Update: it looks like certain dotfiles can trigger this error as well. I’ve submitted a report back to the UXP team so they can investigate further.

1 Like
11

While not ideal, I can at least defend against silent failure/unexpected behavior with something along the lines of:

async function getEntries(selectedDir) {
    try {
        const entries = await selectedDir.getEntries();
        return entries;
    } catch (error) {
        return null;
    }
}

// const selectedDir = ... etc etc 

const entries = getEntries(selectedDir);
if (!entries) {
    // Psuedo code:
    tellUser("Unable to read the selected folder. Please choose a different folder.");
    return; // Exit plugin
}

Curious to know if anyone has found a more eloquent workaround.

1 Like
12

Happy to note that we’ve identified the root cause of the failure in UXP and are working to implement the fix and resolve this soon!

3 Likes