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.

Bug 203464 - AssertionError: FileName: D:\xampp\htdocs\pyrolio\trunk\cake\tests\test_app\plugins\test_plugin\vendors\shells\.svn\tmp#e6a99f61@135f105 tmp at org.netbeans.modules.masterfs.filebasedfs.naming.FileNa
Summary: AssertionError: FileName: D:\xampp\htdocs\pyrolio\trunk\cake\tests\test_app\p...
Status: RESOLVED DUPLICATE of bug 203555
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 7.1
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-10 20:24 UTC by VuuRWerK
Modified: 2011-10-12 13:03 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 181857


Attachments
stacktrace (4.24 KB, text/plain)
2011-10-10 20:24 UTC, VuuRWerK
Details

Note You need to log in before you can comment on or make changes to this bug.
Description VuuRWerK 2011-10-10 20:24:05 UTC
This bug was originally marked as duplicate of bug 200184, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE 7.1 Beta (Build 201109252201)
VM: Java HotSpot(TM) Client VM, 21.0-b17, Java(TM) SE Runtime Environment, 1.7.0-b147
OS: Windows 7

User Comments:
AmLn: May be this is coincidence, but I constantly have lot of problems with external CVS usage. In my project I have several paths (including the one stated in summary of this report) which were removed from CVS repository, and as long as I have to update my project with external script based on CVS its command "cvs update -dP" creates empty directories and then prunes them every update. The problem is that NetBeans catches these temporary created folders and adds them to the project, locking them for removal by CVS, and I receive errors during "cvs update" almost every update when NetBeans is running. How to solve this problem - I have no idea...
This time I've just clicked NetBeans button in taskbar after long inactivity.

VuuRWerK: This happens while using the 'clean-up' command of svn (I'm using Tortoise-SVN)




Stacktrace: 
java.lang.AssertionError: FileName: D:\xampp\htdocs\pyrolio\trunk\cake\tests\test_app\plugins\test_plugin\vendors\shells\.svn\tmp#e6a99f61@135f105
tmp
	at org.netbeans.modules.masterfs.filebasedfs.naming.FileName.<init>(FileName.java:73)
	at org.netbeans.modules.masterfs.filebasedfs.naming.FolderName.<init>(FolderName.java:61)
	at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.createFileNaming(NamingFactory.java:286)
	at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.registerInstanceOfFileNaming(NamingFactory.java:214)
	at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.fromFile(NamingFactory.java:92)
	at org.netbeans.modules.masterfs.filebasedfs.children.ChildrenSupport$1IOJob.run(ChildrenSupport.java:230)
	at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.refreshImpl(FolderObj.java:444)
	at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.refresh(BaseFileObj.java:796)
	at org.netbeans.modules.masterfs.filebasedfs.fileobjects.Fo
   at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.computeChildren(FolderObj.java:196)
   at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.getChildren(FolderObj.java:153)
   at org.openide.loaders.DataObjectPool.getTargets(DataObjectPool.java:714)
   at org.openide.loaders.DataObjectPool.access$600(DataObjectPool.java:60)
   at org.openide.loaders.DataObjectPool$FSListener.fileDeleted(DataObjectPool.java:633)
   at org.openide.filesystems.FCLSupport$DispatchEventWrapper.dispatchEventImpl(FCLSupport.java:148)
Comment 1 VuuRWerK 2011-10-10 20:24:10 UTC
Created attachment 111810 [details]
stacktrace
Comment 2 Jaroslav Tulach 2011-10-12 08:10:45 UTC
Good log: http://statistics.netbeans.org/exceptions/messageslog?id=532761
Comment 3 Jaroslav Tulach 2011-10-12 13:03:11 UTC

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