Created attachment 104027 [details]
stacktrace

http://hg.netbeans.org/cnd-main/rev/f733f3b05394

Please disregard my previous comment, I occasionally copy-pasted wrong text.

I was not able to reproduce this so far.

This might happen only if FileObjectBasedFile returned null path.

I pushed code that asserts path != null for FileObjectBasedFile just in FileObjectBasedFile constructor:
http://hg.netbeans.org/cnd-main/rev/e4b42ca3cb4f

Any comments on how to reproduce are appreciated.

Integrated into 'main-golden', will be available in build *201012150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e4b42ca3cb4f
User: Vladimir Kvashin <vkvashin@netbeans.org>
Log: better diagnostic for #193340 -  IllegalArgumentException: Parameter file was not normalized. Was null instead of null

let's evaluate exceptions as P2 issues

stopd, any details how to reproduce this bug?

Ok, I played a bit around and got some steps to reproduce it on my machine:

A freshly started Netbeans and inside an empty project group:
1. Create new "C/C++ Application" with a main file
2. Right click main.cpp in "Source Files" folder and do "Remove from Project"
3. Right click the project in the "Projects" view and do "Add Existing Item" and choose the main.cpp file
4. Left click once on the newly added main.cpp file
5. Right click once on the newly added main.cpp file
6. Click "Remove from Project"
7. Right click once the project in the "Projects" view
8. Click "Add Existing Item" 

I sometimes need to repeat steps 4 to 8 two or three times (adding the file on step 8 when no exception comes up). Always inserting the file and clicking on it and then without selecting anything else remove and add it using the context menu only.

thanks.
And what is Files of Type filter?
Because by default I have "All Files" and exception is from another filter.
Can you submit exception again when dialog appears?

Thanks,
Vladimir.

I submitted another occurrence of the exception but this time it happened with the all files filter. 

I think my steps before were probably just a coincidence. Instead if I add a file once (the name is kept as the default in the open dialog) and then repeatedly invoke the "Add Existing Item" context menu and just close the dialog, sooner or later the exception comes up.

*** Bug 193523 has been marked as a duplicate of this bug. ***

Created attachment 104309 [details]
patched fs module

Created attachment 104310 [details]
patched utils.jar

could you, please, replace your jar files with attached files to get more tracing.

Thanks!
Vladimir.

files to replace with attached versions are:

netbeans/cnd/modules/org-netbeans-modules-cnd-utils.jar
netbeans/platform/core/org-openide-filesystems.jar

from user:
  Product Version         = NetBeans IDE Dev (Build nbms-and-javadoc-6348-on-101218) (#c87f4bc20449)
  Operating System        = Windows 7 version 6.1 running on x86
  Java; VM; Vendor        = 1.6.0_22; Java HotSpot(TM) Client VM 17.1-b03; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_22-b04
  Java Home               = C:\Program Files (x86)\Java\jdk1.6.0_22\jre
  System Locale; Encoding = en (nb); Cp1252

SEVERE [MIMESupport]: input file null iof class sun.awt.shell.Win32ShellFolder2
java.lang.IllegalArgumentException: Parameter file was not normalized. Was null iof class sun.awt.shell.Win32ShellFolder2 path = C:\Projects\Java\CppApplication\Makefile parent= C:\Projects\Java\CppApplication canonical = null instead of null iof class sun.awt.shell.Win32ShellFolder2 path = C:\Projects\Java\CppApplication\Makefile parent= C:\Projects\Java\CppApplication
	at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:1015)
	at org.netbeans.modules.cnd.utils.cache.CndFileUtils.toFileObject(CndFileUtils.java:130)
[catch] at org.netbeans.modules.cnd.utils.MIMESupport.getFileMIMEType(MIMESupport.java:90)
	at org.netbeans.modules.cnd.utils.filters.HeaderSourceFileFilter.accept(HeaderSourceFileFilter.java:73)
	at javax.swing.JFileChooser.accept(JFileChooser.java:1576)
	at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run0(BasicDirectoryModel.java:231)
	at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run(BasicDirectoryModel.java:211)

Looks like JDK related bug which we can not fix.
can you try what is advised in topic http://wiki.netbeans.org/FaqWindowsCPU
and put "nb.FileChooser.useShellFolder=false" into netbeans.conf

Disabling the places bar by using "nb.FileChooser.useShellFolder=false" did not change anything



Using an older JDK caused a slightly different stack trace but is probably the same problem.

Product Version         = NetBeans IDE Dev (Build nbms-and-javadoc-6348-on-101218) (#c87f4bc20449)
Operating System        = Windows 7 version 6.1 running on x86
Java; VM; Vendor        = 1.6.0_20; Java HotSpot(TM) Client VM 16.3-b01; Sun Microsystems Inc.
Runtime                 = Java(TM) SE Runtime Environment 1.6.0_20-b02
Java Home               = C:\Program Files (x86)\Java\jdk1.6.0_20\jre
System Locale; Encoding = en (nb); Cp1252

SEVERE [org.openide.util.Exceptions]
java.lang.NullPointerException
	at sun.awt.shell.Win32ShellFolder2.pidlsEqual(Win32ShellFolder2.java:498)
	at sun.awt.shell.Win32ShellFolder2.equals(Win32ShellFolder2.java:491)
	at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:1005)
	at org.netbeans.modules.cnd.utils.cache.CndFileUtils.toFileObject(CndFileUtils.java:130)
	at org.netbeans.modules.cnd.utils.MIMESupport.getFileMIMEType(MIMESupport.java:90)
	at org.netbeans.modules.cnd.utils.filters.AllSourceFileFilter.accept(AllSourceFileFilter.java:81)
	at javax.swing.JFileChooser.accept(JFileChooser.java:1576)
	at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run0(BasicDirectoryModel.java:231)
[catch] at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run(BasicDirectoryModel.java:211)



I also tried a recent JDK7 build I have installed. I couldn't provoke the exception in this case.

can someone familiar with JDK bugs evaluate, please?

I think, key information is in comment #15 (which was generated with patched version of fs module).
Looks like normalization of file with path "C:\Projects\Java\CppApplication\Makefile" on Windows 7 went wrong due to corresponding canonical File for it is something with "null" as toString presentation
Canonical file itself is not null, as we can see it is instance of sun.awt.shell.Win32ShellFolder2.
Original file is also instance of sun.awt.shell.Win32ShellFolder2.

*** Bug 194957 has been marked as a duplicate of this bug. ***

Another simple steps to reproduce:
- create Subprojects application 
- open main.cc
- restart IDE
- call File->Open File...
Result: Exception occurs:
java.lang.IllegalArgumentException: Parameter file was not normalized. Was null
instead of null
    at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:1012)
    at
org.netbeans.modules.cnd.utils.cache.CndFileUtils.toFileObject(CndFileUtils.java:163)
    at
org.netbeans.modules.cnd.utils.MIMESupport.getFileMIMEType(MIMESupport.java:86)
    at
org.netbeans.modules.cnd.utils.filters.HeaderSourceFileFilter.accept(HeaderSourceFileFilter.java:73)
    at
org.netbeans.modules.cnd.utils.filters.CndOpenFileDialogFilter$Adapter.accept(CndOpenFileDialogFilter.java:91)
    at
org.netbeans.modules.cnd.utils.filters.CndOpenFileDialogFilter$HeaderFilter.accept(CndOpenFileDialogFilter.java:114)
    at javax.swing.JFileChooser.accept(JFileChooser.java:1576)
    at
javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run0(BasicDirectoryModel.java:231)
    at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThr

This bug already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=174969

Cannot reproduce.

Also cannot find any Java bug report in bugs.sun.com which would be related to "null" as toString of File.

Cannot do anything about it in JDK Problems category, cannot file as a Java bug myself without being able to provide them any details about the problem.

All exceptions gathered here are related to the same stacktrace going through org.netbeans.modules.cnd.utils.cache.CndFileUtils. No exceptions going through any other code path unrelated to CND.

Reassigning back to CND for further evaluation and most probably fixing in CND.

(In reply to comment #23)
> Cannot reproduce.
> 
> Also cannot find any Java bug report in bugs.sun.com which would be related to
> "null" as toString of File.
> 
> Cannot do anything about it in JDK Problems category, cannot file as a Java bug
> myself without being able to provide them any details about the problem.
> 
> All exceptions gathered here are related to the same stacktrace going through
> org.netbeans.modules.cnd.utils.cache.CndFileUtils. No exceptions going through
> any other code path unrelated to CND.
> 
> Reassigning back to CND for further evaluation and most probably fixing in CND.
Have a look at my comment http://netbeans.org/bugzilla/show_bug.cgi?id=193340#c15
which I generated with patched FileUtil.
It means that getCanonical for sun.awt.shell.Win32ShellFolder2 returns "null" string (not null object)
I'd prefer FileUtil.toFileObject to be aware of this instead of hacking on our side.

Patch?

(In reply to comment #25)
> Patch?
What do you mean?
I've just changed Logging in toFileObject to see more details to be smth like:

                    LOG.log(Level.WARNING, null, new IllegalArgumentException(
                    "Parameter file was not " + // NOI18N   
                    "normalized. Was " + file + " iof " + file.getClass() + " path=" + file.getPath() + " parent=" + file.getParent() +
                            " canonical = " + file.getCanonicalPath() + 
                            " instead of " + normFile + " iof " + normFile.getClass() + " path=" + normFile.getPath() + " parent=" + normFile.getParent()
                    ));

What do I mean? Whether you will provide a fix or not? Because, with all my respect, this is not P2 bug in filesystems, at most it is an enhancement for filesystems and I am not in mood to implement enhancements day before code freeze.

         if (asserts) {
             File normFile = normalizeFile(file);
             if (!file.equals(normFile)) {
-                LOG.log(Level.WARNING, null, new IllegalArgumentException(
+                LOG.log(file.getClass().getName().startsWith("sun.awt.shell") ? Level.INFO : Level.WARNING, null, new IllegalArgumentException( // NOI18N
                 "Parameter file was not " + // NOI18N   
                 "normalized. Was " + file + " instead of " + normFile
                 ));

Jarda, can you apply this simple fix in FileUtil.toFileObject to prevent exception dialog?
(Am I right, that dialog is shown for levels from warning and above?)

Guys, the exception is printed only with asserts on - e.g. it will not affect 7.0 FCS. I prefer to deal with the case in less rush then => TM=Next.

(In reply to comment #30)
> Guys, the exception is printed only with asserts on - e.g. it will not affect
> 7.0 FCS. I prefer to deal with the case in less rush then => TM=Next.
You are right, no need for integration in to 7.0 but can I apply proposed fix in trunk?
It's rather annoying on Windows for users of dev builds

I still have not simulated the problem myself, but I believe that rather than changing the error verbosity, we shall fix 

FileUtil.normalizeFileOnWindows

to just ignore this case and return something meaningful. I can see there are some tricks for Windows Vista. Maybe we need new ones for Windows 7.

I agree, it's much better to fix FileUtil.normalizeFileOnWindows

*** Bug 196627 has been marked as a duplicate of this bug. ***

Created attachment 107571 [details]
stacktrace

I checked in ergonomics#336772e876bb, but I did not test it. The code is based on Vladimir's "if", so it could work. Please verify the fix.

Integrated into 'main-golden', will be available in build *201104150401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/336772e876bb
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #193340: Ignore special UI subclasses of File used on Windows

*** Bug 199447 has been marked as a duplicate of this bug. ***

*** Bug 211848 has been marked as a duplicate of this bug. ***

Occurred on NB 7.2

I need a bit more information then "occured in 7.2" to do something with the bug. Closing. Btw. there is no report from 7.2 among the list of exception reporter duplicates...

Jarda, can you for simplifying the issue investigation to add 
file.getClass().getName() to the log report (in 7.2)?

If I remember correctly 7.2-based issue has happened in the FileChooser with custom Files and FileObject based Filter

Thanks,
Vladimir.

*** Bug 213424 has been marked as a duplicate of this bug. ***