Created attachment 14882 [details]
Exception stack trace

I'm using JDK 1.5 b51 on Linux and it works fine.

Reassigning to Radek for evaluation. In ProjectChooserAccessory you
can see this code (simplified for quotation):

File dir = ...;
if (!dir.isDirectory()) {
    return false;
}
FileObject fo = FileUtil.toFileObject(dir);
return ProjectManager.getDefault().isProject(fo);

PM.iP passes the same FileObject to PM.cFP which calls

assert dir.isFolder();

I.e. there is some File which exists on disk and is a directory but
which masterfs claims is not a folder.

I think Jesse is right. I suspect that some special Windows folders
(My Computure, My Documents, Trash, etc.) might be confusing the
project chooser.

There must be some difference between 1.5 and 1.4.2, because the same
action on the same system results in different behaviors. Someone
should investigate what the difference is, because there might also be
a performance hit.

Another related bug and possibly a hint: I also got the following
error when trying to open the project chooser on 1.5 beta 2:

"The drive or network connection that the shortcut 'Some File.lnk'
refers to is unavailable. Make sure that the disk is properly inserted
or the network resource is available, and then try again."

This is a system message which blocks AWT (thread dump attached
shortly). It shows that Swing's File Chooser is trying to resolve
Windows links. Why? Why on JDK 1.5 and not with 1.4.2?

There really was a broken shortcut on my Windows desktop. Deleting it
fixed the problem (until I ran into the AssertionError). Now I only
get the latter originally reported problem.

Neither of my native Windows apps told me there was a broken link on
my desktop. Why should a Java app care?

Both problems could probably be reported as separate issues. It seems
to me, however, that the root causes might be related, so I keep them
under one issue for now.

Created attachment 14888 [details]
Thread dump while system error blocks AWT.

Looks like the JDK 1.5 Win32 file chooser is trying to do trickier
stuff than it used to... probably we will need to file some JDK bugs.
E.g. to request that an empty A: drive is not returned as a disk root.

BTW I added earlier and more descriptive error checking of parameters,
so you should get a better message than an assertion error now:

committed     Up-To-Date  1.6        
projects/projectapi/src/org/netbeans/api/project/ProjectManager.java

Yep. This is an evidence. A Windows shortcut (.lnk file) is apparently
being passed as a directory:

java.lang.IllegalArgumentException: Attempted to pass a non-directory
to isProject:
MasterFileObject@89ca51[file:/C:/Documents%20and%20Settings/honza/Desktop/Control%20Panel.lnk]
	at
org.netbeans.api.project.ProjectManager.isProject(ProjectManager.java:267)
...
(full stack trace attached)

Created attachment 14896 [details]
IllegalArgumentException stack trace

Honza, perhaps java.io.File is reporting this file as both isFile()
and isDirectory() at once? (In contradiction to the File.isFile
Javadoc.) However I am not sure how that would cause this bug, since
AFAICT the relevant code (LocalFileSystem, I think) only calls
isDirectory, never isFile, just like ProjectChooserAccessory is doing:

protected boolean folder (String name) {
    return getFile (name).isDirectory ();
}
private File getFile (String name) {
    // XXX should this be name.replace('/', File.separatorChar)? Cf.
BT #4745638.
    return new File (rootFile, name);
}

Note the unaddressed comment (mine, from a long time ago). Presumably
LFS is actually constructing

new File("C:/Documents and Settings/honza/Desktop/Control Panel.lnk")

(note the forward slashes) and this is reporting !isDirectory(). Since
File calls java.io.FileSystem.normalize(String) the direction of the
slashes probably doesn't matter (but should check this).

Or perhaps that File is reporting different results for isDirectory -
first true then false?

Well Java_java_io_WinNTFileSystem_getBooleanAttributes in
j2se/src/windows/native/java/io/WinNTFileSystem_md.c does not seem
capable of making a java.io.File be isFile() and isDirectory() at
once. It does call GetFileAttributesW (in Win32) and checks for the
FILE_ATTRIBUTE_DIRECTORY flag.

Huh, something to check: make the File corresponding to that shortcut
and see what getCanonicalFile returns. Maybe one is considered a
directory and the other a file, or something perverse like this.

Hmm, I tried the suggested experiments. IMO, results do not show
anything suspicious. Both original and canonical instances of
File("C:/Documents and Settings/honza/Desktop/Control Panel.lnk")
return *true* for isFile() and *false* for isDirectory().

Tested with JDK 1.5.0-beta2 (b51).

See
http://developer.java.sun.com/developer/bugParade/bugs/4356160.html

Note 'fixed in tiger-beta-2'. That might explain the different
behavior with previous JDK versions.

Interesting comment added on April 27, 2004:

"Also note that in 1.5 beta2 and later, the test for isDirectory()
above will always be false, as this is now handled internally."

Fixed:
Curiously on Windows may occure dir.isDirectory () == dir.isFile () ==
true. 

/cvs/projects/projectui/src/org/netbeans/modules/project/ui/ProjectChooserAccessory.java,v
new revision: 1.10; previous revision: 1.9


Not sure if this fixes also the second one problem
with links that are declared as unavailable. I wasn't able to
reproduce it - please verify. 

Radek can you explain what is going on in this issue report please?
For which class of files is it both isFile() && isDirectory()? Have
you filed a high-priority bug report for the JRE saying that the
documented semantics of java.io.File are being violated? Putting in a
patch to one GUI class is not going to prevent this problem from
causing other P1 bugs down the road.

I'm no longer able to reproduce the reported problems (passing a
non-directory and broken .lnk reference) w/ JDK 1.5 beta2 (b51).
Hopefully, Radek's change fixes it.

Not reported as a JDK bug yet (will be reported before this issue is
closed). 

dir.isDirectory () == dir.isFile () == true
--------------------------------------------
class: sun.awt.shell.Win32ShellFolder2
for *.lnk files like:
C:/Documents and Settings/rm111737.PRAGUE/Desktop/Control Panel.lnk
stacktrace: see attachment

Created attachment 14916 [details]
thread dumpstack

OK, so what was wrong with the previous code in
ProjectChooserAccessory? It was calling isDirectory(), which returned
true. Why was the FileObject claiming it was !isFolder()?

Cause:
dir.isDirectory () == true but new File (dir).isDirectory () == false

In ProjectChooserAccessory.isProjectDir is called
ProjectManager.getDefault().isProject( fo ) just in case and there is
expected that fo represents folder. This assumption is based on
condition that dir.isDirectory () == true (but lnk files are not
folders which is obvious if you call new File (dir).isDirectory ())

So, this fix tries to avoid usage of sun.awt.shell.Win32ShellFolder2
(dir) and uses java.io.File instead. Maybe this should be done in
FileUtil.normalizeFile.

Q: Why was the FileObject claiming it was !isFolder() ? 
A: Because *.lnk file aren't folders (even if they address folders)

OK, I think I get it - the Win32ShellFolder2 reported itself as a
directory, but the java.io.File with the same path does not. My that's
evil.

Agreed that FileUtil.normalizeFile would be a reasonable place to
handle this problem.

Fixed in FileUtil.normalizeFile:
/cvs/openide/src/org/openide/filesystems/FileUtil.java,v  <-- 
FileUtil.java
new revision: 1.94; previous revision: 1.93

[Build refactoring/metastavbicka040513, jdk 1.5.0-beta2-b50, WinXP SP1]

I've got messages like
"The drive or network connection that the shortcut 'Some File.lnk'
refers to is unavailable. Make sure that the disk is properly inserted
or the network resource is available, and then try again."

and 

"Insert disk into E" 
(my CD drive) several times when using any filechooser in the IDE.

It seems to be a regression in JDK, as I got these messages even
without the IDE, using simple and reproducible test case (simplified
version from JavaDoc):

    public static void main(String[] args) {
        JFileChooser chooser = new JFileChooser();
        int returnVal = chooser.showOpenDialog(null);
        if(returnVal == JFileChooser.APPROVE_OPTION) {
           System.out.println("You chose to open this file: " +
                chooser.getSelectedFile().getName());
        }
    }

That's pretty annoying message (comming from WinOS) as you need to
ignore it everytime when you open FileChooser or do any operation
within it (including Change Directory Operation).

Rollbacked previous commit FileUtil.normalizeFile cause there are
strange sun.awt.shell.Win32ShellFolder2 files (::{blabla} registry ID
or got knows what is it) and if you convert it to java.io.File then
storm of Exceptions follows action open project. Curiously File
(::{blabla}).getParent () returns something like  C:/Documents and
Settings/rm111737.PRAGUE/Desktop. 

Eeek. Maybe the conversion to java.io.File can happen only for files
which exists()?

There is reported Bug Id:  5049016 by Jan Chalupa (1.5 REGRESSION) -
planned to be fixed. 

*** Issue 43580 has been marked as a duplicate of this issue. ***

There were a few commits related to this issue in last two weeks.  I
consider this issue as fixed.

Verified. The bug no longer occurs in 4.0 builds.