macOS JFileChooser.showOpenDialog(null) requires sudo on some Macs?

[ArtOfWarfare]

I have two 2012, non-retina 13" MacBook Pros. They're both running OS X 10.9.0 and both have Java runtime 1.7.0_45.

public static void main(String[] args) {
    try {
        JFileChooser picker = new JFileChooser();
        picker.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES);
        picker.setMultiSelectEnabled(true);
        picker.setFileView(new FileView() {
            @Override public Boolean isTraversable(File file) {
                if (file.isDirectory() && file.getName().startsWith("my-prefix")) {
                    return false;
                }
                return null;
            }
        });
        System.out.println("About to show the file picker.");
        if (picker.showOpenDialog(null) == JFileChooser.APPROVE_OPTIONS) {
            for (File file : picker.getSelectedFiles()) {
                openFile(file);
            }
        } else {
            System.exit(0);
        }
        System.out.println("File picker shown successfully.");
    } catch (Exception e) {
        System.out.println("Failed to show file picker.);
        e.printStackTrace();
    }
}

This is packaged as a jar. If it is ran using

java -jar (path to jar)

Then on one Mac, the following always appears:

About to show the file picker.

The menubar changes to have the title of the jar, the java icon gets added to the dock, and the picker appears. Once the user selects a file, it says

File picker shown successfully.

On the other Mac, it only behaves that way if you execute it using sudo.

If you don't use sudo, it'll display the first message, the java icon gets added to the dock, and the menubar changes to have the title of the jar, but the picker never appears. Expose doesn't show the picker (it does otherwise.) No error messages are output.

On both computers the user logged in is an admin. The computers are so similarly set up I can't think of anything that might be causing the issue. Permissions are set up the same. Any suggestions on what might be causing this inconsistency?

Edit: Tried on a third 2012 MacBook Pro running Mavericks and the same version of Java. It works just fine without sudo, same as the first.

 

[chown33]

If that's your exact code, then you've misspelled isTraversable():

            @Override public Boolean [COLOR="Red"]isTravesable[/COLOR](File file) {

Consequently, you haven't overridden the default method.

One thing I'd do is throw some println's into isTraversable(), and look at every File's absolute pathname being handed to it. I'd be looking for the possibility of a directory that isn't readable or searchable for the current user-id (insufficient permissions).

Another thing I'd do is create the JFileChooser using the File-arg or String-arg constructor, so I have direct control over which directory it's presenting. Start with a known-readable directory. The path "/Users/Shared" is a good choice, because it's read/write/search to all users.

You should also be able to look at system properties to discover "the user's default directory" that the no-arg constructor refers to. It may not be what you think it is.

Finally, try creating a new non-admin user, then login or quick-switch to that, and run the test there.

 

[ArtOfWarfare]

If that's your exact code, then you've misspelled isTraversable():

            @Override public Boolean [COLOR="Red"]isTravesable[/COLOR](File file) {

Consequently, you haven't overridden the default method.

One thing I'd do is throw some println's into isTraversable(), and look at every File's absolute pathname being handed to it. I'd be looking for the possibility of a directory that isn't readable or searchable for the current user-id (insufficient permissions).

Another thing I'd do is create the JFileChooser using the File-arg or String-arg constructor, so I have direct control over which directory it's presenting. Start with a known-readable directory. The path "/Users/Shared" is a good choice, because it's read/write/search to all users.

You should also be able to look at system properties to discover "the user's default directory" that the no-arg constructor refers to. It may not be what you think it is.

Finally, try creating a new non-admin user, then login or quick-switch to that, and run the test there.

No - it's not my exact code. The actual code has setting up the JFileChooser in one spot then displaying it in another, so that I can set it up once but then display it multiple times, but since the problem appears right from the get-go with the app, the code I wrote in the post is the same as what's getting executed. That's where the typo came from (not copying and pasting every line) - my code actually compiles and runs properly. Warnings are turned on so it would let me know if my @Override wasn't actually changing a default implementation.

Anyways, I added in checks for file permissions, using

picker.getCurrentDirectory().canRead()

It returns true on every computer. I also had it print out the currentDirectory. In every case it's the user's home directory. So I'm still at a loss for why it's not working.

I wish showOpenDialog() didn't block... if it didn't, I'd try printing out a few variables about it for inspection. As is. If it were my computer exhibiting the problems I could try using Eclipse's debugger... but it's someone else's computer and I'd rather not kick them off of it for an hour to get Eclipse's debugger running when potentially it wouldn't even reveal anything.

Although there's at least two work arounds for the one (of three) computers where it doesn't work...
1 - My program accepts arguments when it's launched from the command line. It'll interpret them as directories to open.
2 - It works when you run it with sudo.

 

[chown33]

No - it's not my exact code. The actual code has setting up the JFileChooser in one spot then displaying it in another, so that I can set it up once but then display it multiple times, but since the problem appears right from the get-go with the app, the code I wrote in the post is the same as what's getting executed. That's where the typo came from (not copying and pasting every line) - my code actually compiles and runs properly. Warnings are turned on so it would let me know if my @Override wasn't actually changing a default implementation.

Please post a well-isolated and compilable test-case. Your posted code doesn't compile. For one, it's not in a class. But putting it into a class is insufficient; it still fails to compile. I could fix it so it compiles, but that's no guarantee that running my code will cause the malfunction on your system.

Add the println() to your isTraversable() method, and ensure it is being called.

Run the test-case and make sure it produces the same results as your other program, both with and without 'sudo'. If it works correctly, post a screenshot of the dialog, also copy and paste the println'ed output and post it here.


Create a new admin account on the malfunctioning computer. Login or fast-user-switch to that account. Run the compiled test-case there. Does it show the same malfunction as the main admin account?

Repeat with a non-admin new-user account. What happens?

Instead of using 'sudo', use the 'su' command and switch to a specific non-admin user that doesn't show the malfunction. That is, suppose user bob is a non-admin user, and the test-case doesn't malfunction when run as bob (fast user switch or login). Suppose alice is the admin user that DOES show the malfunction. So login as alice, then use 'su bob' to temporarily become bob. This will require bob's password. Then under this condition, run the test-case.


It's conceivable that something in the directory being presented, or in some supplementary part of the picker dialog, requires elevated privileges in order to resolve correctly. For example, a symlink, an unowned file, etc.

That's just a guess, because I don't know what's actually being presented when you run the picker test using 'sudo'. That's one reason I asked for a screenshot of the picker when it's actually being run by the test-case.