This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Unable to open project on JDK 1.5 beta 2 (b51) | ||
---|---|---|---|
Product: | platform | Reporter: | Jan Chalupa <jchalupa> |
Component: | Filesystems | Assignee: | rmatous <rmatous> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jglick, mmirilovic |
Priority: | P3 | Keywords: | JDK_SPECIFIC |
Version: | 4.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Exception stack trace
Thread dump while system error blocks AWT. IllegalArgumentException stack trace thread dumpstack |
Description
Jan Chalupa
2004-05-15 20:17:57 UTC
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. |