Created attachment 53201 [details]
stacktrace

Build: NetBeans IDE 6.0 RC2 (Build 200711201000)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Linux, 2.6.22-14-386, i386

User Comments: 
I refactored a large number of classes to extract their interfaces and then refactored again to move those interfaces to another package.

Created attachment 53463 [details]
stacktrace

I cannot reproduce according to jskrivanek steps to reproduce. Jirka, is it really reproducible for you?

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

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

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

This is becoming more and more serious: 2 duplicates, 12 reported exceptions in EXCEPTIONS_REPORT ...

I can't reproduce it (NB 6.0 FCS), but we need at least some evaluation. 

Yes, I can reproduce it exactly as I wrote.

Well, I was able to reproduce it once (when all files from renamed package were opened!), but I've tried same scenario
repeatedly and I haven't been able to reproduce it any more ;(

My experience has been that the first package refactoring works fine.  It is later ones.  Try this:
 - Create two interdependent projects, one and two
 - Create one.A
 - Create a unit test for one.A that refers to a package private member of one.A (don't know for sure that this step is necessary)
 - Follow the same steps for project b creating two.B
 - Make one.ATest refer to two.B (also not sure if this is necessary)
 - Rename package one to org.foo.bar
 - Rename the test package one (at this point you'll notice that the parser no longer works on ATest - it can't see the class A at all)
 - Now rename package two to something else - that should get you the exception

I'm able to reproduce. The more files in package the higher chance to reproduce it. With 100 or more almost 100%.

Problem seems to be race condition, folderlist computing is running when renaming of files is in progress, some of files
are already renamed and fall into new package and the rest is still at the same place.

I'm going to investigate more, although I don't think the problem is in FS library. 

Jesse coded the new ordering infrastructure.

Although, I'm able to reproduce now, I've never end up with broken sources

Calling body of
org.netbeans.modules.refactoring.java.plugins.PackageRename$PackageRenamePlugin$RenameNonRecursiveFolder.setName
solves the problem (at least I'm not able to reproduce).

Calling body of
org.netbeans.modules.refactoring.java.plugins.PackageRename$PackageRenamePlugin$RenameNonRecursiveFolder.setName
in AtomicAction solves the problem (at least I'm not able to reproduce).

I didn't find any problem in FS. Can be hotfixed by atomicaction in refactoring code, or not throwing IAE from ordering,
but probably the right fix will be in folderlist. Sending for evaluation to datasystems. 

Introduced by jglick in FolderList.java, rev. 1.24.

Yarda maintains FolderList incl. its rather complex threading semantics. FileUtil.getOrder has the rather simple and
obvious precondition that all the files passed to it must be children of the same folder. If FolderList.carefullySort is
violating this then there is some problem in the code which collects lists of files to be sorted, which I did not touch.
The previous code was probably trying to sort old and new files together but did not detect this inconsistency.

I don't see any problem with using an AtomicAction in refactoring code as a fix for the symptom; a rewrite of FolderList
to make it threadsafe would probably be more dangerous.

If it was my code, I would fix the problem. But it is your code! Before your rewrite in rev. 1.24 there were no 
IllegalArgumentException problems. You have introduced them by converting from DataObject to FileObjects and then 
back. I am sad to see that you have enough courage to spoil one's code, but then you do not feel responsible for the 
consequences:

1.2          (jtulach  02-Apr-03):      */
1.24         (jglick   16-Jun-07):     private List<DataObject> carefullySort(List<DataObject> l, FolderOrder c) {
1.16         (jtulach  04-Apr-06):         final boolean LOG = err.isLoggable(Level.FINE);
1.16         (jtulach  04-Apr-06):         if (LOG) err.fine("carefullySort on " + folder);
1.2          (jtulach  02-Apr-03):         Collections.sort (l, c);
1.24         (jglick   16-Jun-07):         Map<FileObject,DataObject> files = new 
LinkedHashMap<FileObject,DataObject>(l.size());
1.24         (jglick   16-Jun-07):         for (DataObject d : l) {
1.24         (jglick   16-Jun-07):             FileObject f = d.getPrimaryFile();
1.24         (jglick   16-Jun-07):             f.removeFileChangeListener(weakFCL);
1.24         (jglick   16-Jun-07):             f.addFileChangeListener(weakFCL);
1.24         (jglick   16-Jun-07):             files.put(f, d);
1.24         (jglick   16-Jun-07):         }
1.24         (jglick   16-Jun-07):         List<FileObject> sorted = FileUtil.getOrder(files.keySet(), true);
1.24         (jglick   16-Jun-07):         List<DataObject> dobs = new ArrayList<DataObject>(sorted.size());
1.24         (jglick   16-Jun-07):         for (FileObject f : sorted) {
1.24         (jglick   16-Jun-07):             dobs.add(files.get(f));
1.2          (jtulach  02-Apr-03):         }
1.24         (jglick   16-Jun-07):         return dobs;
1.2          (jtulach  02-Apr-03):     }
1.2          (jtulach  02-Apr-03):

If you want me to review your fix, I am ready. If you want to insist on me being responsible, reassign back, but next 
time please do not commit anything into areas that I am responsible for without my explicit prior permission. Thanks.

> I don't see any problem with using an AtomicAction in refactoring code as a fix for the symptom.

Fix on refactoring side (however safe) is rather workaround, but not a real fix. It can be used on some high resistance
branch, but trunk should be fixed properly.

For jbecicka: even if there didn't exist this issue, I believe that using of atomicaction in refactoring is right
approach, because FS fires events in the same thread and thus whatever wrong code in any FCL impl. may cause breaking
refactoring in half way and thus cause broken sources. Fortunately in this case IAE was thrown from other thread.

Moves inserted into atomic action:
Checking in PackageRename.java;
/cvs/refactoring/java/src/org/netbeans/modules/refactoring/java/plugins/PackageRename.java,v  <--  PackageRename.java
new revision: 1.9; previous revision: 1.8
done

Build: NetBeans IDE 6.0 RC2 (Build 200711201000)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Windows XP, 5.1, x86

User Comments: 

Created attachment 53810 [details]
stacktrace

Looks like I have to fix the 1.24, jglick, 16-Jun-07 commit.

#122295: Sorting only FileObjects that have the valid parent, e.g. that are not moved while processing the order

RCS file: /cvs/openide/loaders/test/unit/src/org/openide/loaders/FolderOrderIllegalTest.java,v
done
Checking in test/unit/src/org/openide/loaders/FolderOrderIllegalTest.java;
/cvs/openide/loaders/test/unit/src/org/openide/loaders/FolderOrderIllegalTest.java,v  <--  FolderOrderIllegalTest.java
initial revision: 1.1
done
Checking in src/org/openide/loaders/FolderList.java;
/cvs/openide/loaders/src/org/openide/loaders/FolderList.java,v  <--  FolderList.java
new revision: 1.28; previous revision: 1.27
done
IDE: [4.12.07 12:18] Committing finished

Patch looks reasonable; a conservative check which would prevent the exception from being thrown, possibly at the cost
of an incorrect order in the system file system after an unusual settings change. In general the threading model of
Filesystems and Datasystems is very poor (no true atomic actions, for example), so such a minor problem would hardly be
worth fixing if it even existed. Another theoretical possibility is that some Filesystems call coming in during the
modified loop would cause files.keySet() to again have an inconsistent list of parents, thus throwing the same IAE; but
this seems unlikely and is impossible to defend against anyway within current architecture.

I am not very familiar with the threading semantics of the folder recognizer code but the test does appear to exercise
the bug.

Thanks for fixing. Of course I would have gotten to this sometime before 6.1 freeze but I am not fixing sub-P1s at the
moment.

Thanks for review.

Re. "files.keySet() to again have an inconsistent list of parents" - fileObject.getParent() is "final" - e.g. returns 
always the same result for the whole lifetime of an FileObject in all existing file system implementations. That is 
why I think this cannot happen.

Re. "incorrect order" - if a change happens while the folder list is being computed, a refresh is scheduled for later 
and the order will be notified sometimes in future. At the end, when the file system becomes stable, the result of 
DataFolder.getChildren will correctly reflect that stable state.

Verified.

Reopening - reproduced in NetBeans IDE Dev (Build 200807040101)
http://statistics.netbeans.org/exceptions/detail.do?id=124722

False alarm - I filed issue 149471 against exception reporter.

Verified.

repoducible when downloading files using ftp(built-in) in php project 

Product Version: NetBeans IDE Dev (Build 101015-6139878acc12)
Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01-279

Petr, I remember you mentioned that you have two stacktraces showing the different FileNaming creation paths, right?

Yes, that is issue #190319

The recent improvements in bug 190319 shall help this issue too.

*** This bug has been marked as a duplicate of bug 190319 ***