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.
[build of 040514 sources, JDK 1.4.2_02] I get frequent 'There is no disk in drive A' system errors when using recent trunk builds on Win XP. They seem to occur pretty randomly, but I suspect that the All Files view might be the cause. Sometimes, I get the error when I open the All Files view, other times I have to click on the A: drive node in the view. Occasionally, the error occurs upon IDE restart. The error is reported via a modal system dialog which blocks IDE's event queue. The main window doesn't repaint while the error is displayed and the IDE is blocked, until the dialog is confirmed by the user. This is also a blocker for some of the automated test suites. I think I recall seeing a similar problem reported against the platform builds some time ago (probably in the 3.5 time).
Created attachment 14883 [details] A screen shot with the error message. AWT blocked.
Found it. See issue #23725. Forgot to mention that A: is a floppy drive on my Win XP box.
Created attachment 14884 [details] Thread dump when blocked.
Probably a masterfs issue.
Not sure if this is MasterFS issuse. According to stacktrace there is called ProjectManager.findProject on "A:" FileObject - what does it mean ?. Does it mean that user created project on drive "A:" and then removed it ? Or user clicked on the A: drive node in the view (seems to be the real cause according to Jan Chalupa comment)? If so then this error message is completely OK - if user wants to work with drive "A:" then drive must be ready or disk in drive "A:" must be inserted. This issue is one of the reasons why I keep on claiming that "All Files" tab shouldn't be part of production build at all. Even if I was able to convert FileObject ("A:") smoothly into java.io.File it would be dangerous and fragile using it because there are just a few methods that can be safely called on java.io.File ("A:") without risk that error message will be shown.
I see this issue as a user problem. I let it open for next investigation . But if it was really true that there is enough to show up "All Files" tab to get this message then please increase priority ASAP.
Yes, a reliable way to reproduce the error is to click on the A: node in explorer. However, the error dialog keeps popping up in other scenarios as well. I believe I got it with a clean userdir even before I got to enabling the All Files view at all. Raising to P1. This must be fixed. Blocks automated test execution on Windows.
Needless to say I have never created any projects on a floppy drive.
OK I think you are right that this could be serious problem. Then I would like to ask you or your team to provide steps how to reproduce or at least some hint e.g. in form of stacktrace (the current proves just that you clicked on drive A:) because I fight with this problem continually and I don't know any way how to reproduce it at the moment.
Ok, one way to reproduce it reliably (without user clicking on the A: node) on my machine: 1. Open All Files view. Only the root of the master FS is displayed (shouldn't it be expanded by default?). 2. Expend the root node. Error "No disk in drive A:" is diplayed. Folder recognizer is the blocking thread this time: "Folder recognizer" daemon prio=2 tid=0x0695f530 nid=0xe54 runnable [7d8f000..7d8fd8c] at java.io.WinNTFileSystem.getBooleanAttributes(Native Method) at java.io.File.isDirectory(File.java:701) at java.io.File.toURI(File.java:608) at org.netbeans.modules.masterfs.MasterURLMapper.getURL(MasterURLMapper.java:52) at org.openide.filesystems.URLMapper.findURL(URLMapper.java:80) at org.openide.filesystems.FileObject.getURL(FileObject.java:704) at org.openide.loaders.BrokenDataShadow.checkValidity(BrokenDataShadow.java:163) ... (see the attachment for the complete thread dump)
Created attachment 14904 [details] Thread dump
David, can you explain why there exist DataShadow on something in drive A: ?
Honza, I tried it (with clean userdir) and it works fine on my WinXP. From the thread dump it looks that some DataObject was created and this actions notifies list of existing broken datashadows in the systems and ask them to recheck whether they are still broken. And some broken shadow (which can lie anywhere) point to a file on A: drive? Strange. Are you able to reproduce it with clean userdir? Perhaps there is some link in your userdir pointing to something on A:? Please let me know. One thing I could do is to log more infromation in this case: FO of the shadow + URL the shadow points to.
So, I was able to get it into the state when the error occurs upon startup (even before the main window is completely painted). Here's what I did: 1. Started with a clean userdir using JDK 1.4.2_02. 2. Opened the 'openide' project. 3. Restarted with JDK 1.5.0 beta2 (b51) [Not sure if this is really important, I just needed to work around issue #43314 - Cannot open project with 1.5 beta2] 4. Opend All Files view. 5. Expanded the root of master FS -- got the 'No disk in drive A' for the first time. Dismissed it. 6. Clicked on the A: node. I know I shouldn't do it :-) Got the error for the second time. Dismissed it again. 7. Expanded the C: node in the All Files view. 8. Restarted the IDE. This time the error appeared before the main window was fully painted. Exception stack trace looks similar to the previous one. Attaching for reference.
Created attachment 14909 [details] Another thread dump
Reproducible with a clean userdir without opening any projects. Steps 1-3 can be safely skipped.
Dtto w/ JDK 1.4.2.
Thanks Honza. I know what is the problem now. It was caused by the issue 42091 but technically speaking it is not regression. DataShadows were rewritten to rely on URLs instead of Filesystem/Path pair. There exists an OperationListener (ShadowChangeAdapter) which besides other things does following: it listens on DataObject creation and tries to update BrokenDataShadow list whenever a new DO is created. And the problem is that when you expand All Files the DOs will be created for all subnodes, i.e. DO("A:"), DO("C:"), ... and these are later asked for URL of its primary file and that shows the irritating dialog. The updating code is wrong. I did not get why it listens on Datasystems layer when it should listen on Filesystems. It looks like potential performance hole. I can try to fix that. I have anyway issue 38348 for it. Other possible solution is to say that DataShadows work only on SystemFS and in that case I could leave everything as is and just ignore DO creation events from non-SFS filesystems.
Honza, I commited hotfix: src/org/openide/loaders/BrokenDataShadow.java new revision: 1.10; previous revision: 1.9 could you please try it and tell me whether it helped? I unfortunatelly cannot reproduce the message box. Even if I click/expand the A: node directly. Perhaps different OS driver/patch?
I don't think the problem is so much in the All Files view as such, as that masterfs is returning all disk roots even for drives which are not available. IMHO using File.listRoots is just too dangerous (*). Suggest that masterfs on Windows initially contain no roots and that roots be added only when someone explicitly requests them via URLMapper, e.g. after opening a project from the file chooser on such a drive. Would that help anything? Or abandon the attempt to provide one masterfs which contains all disk roots. This doesn't seem to have any actual use. There could be multiple filesystems, one per disk root. Would still require some kind of tricks in All Files to only show relevant drives, of course - could start with drives used for NB installation and user dir and open projects, and have some context menu item to add others as desired. Initial hotfix could be to exclude A: and B: from masterfs roots - these seem to be the most common sources of problems since these are usually removable media (that are in fact usually removed since no one uses floppies any more). However if you have a CDROM drive in D: etc. this would not be much help. (*) Could the JRE exclude missing or unloaded drives from File.listRoots? This would certainly help.
I tested with David's patch on 1.5 beta 2. It seems to work. The only way to get the annoying error dialog is to explicitly click on the A: node in the All Files view. This is consistent with the Windows Explorer behavior, so I don't consider it to be an issue. I cannot reproduce the problem just by expanding the master fs root, nor after restarting the IDE with the root node expanded.
I believe that problem is code that get all roots (File.listRoots ()) and then converts them to FileObject . Not important if we have 1 masterfs or many LFS (or masterfs) for individual drives. There must exist some logic that makes decision which Files are available and which not. But problem is that I don't know any way how to do it safely in java because new File ("A:").exists () is the way to hell. Masterfs has some advantage that its FileObject (for A:) is aware of the fact that its fragile and wraps it relatively safely until you request something like getChidren on A:.
Right, so we need to make sure that nothing is calling getChildren on disk roots without a good reason... Possibly bad idea: for the case of disk roots, implement FO.getChildren specially. Call File.list in a separate thread (RP) and block the caller thread. If list() completes within say 1 second, return that value. If it does not complete within that time, return an empty list (fire a children change if it ever does return) and internally mark that disk root as being "slow or missing", and all subsequent getChildren calls within that root should work the same way - operate synch up to one second and asynch afterwards. I know this would be a pain to implement, but I think it could be helpful - even if someone does accidentally try to get children of A: (when there is no disk in the drive), they will just get an empty list within a second, the user cancels the stupid Windows dialog, and masterfs thereafter things that A: is empty.
BTW the All Files tab is slated to be replaced by a Favorites tab, which need not have the same UI. (Adding Jano and Nenik to CC for this reason.) In particular, I think it would be preferable to not include disk roots by default (maybe don't include *anything* by default), and just let the user select (with a file chooser) particular folders to show. This would probably be more useful UI, and would bypass this kind of problem w.r.t. the user clicking randomly in the tab. Of course you still have to worry about file accesses coming from other places, esp. the file chooser used to open projects - cf. our current hack of disabling the isProject check on disk roots, since it needs to check for subdirs.
I think that the best solution for this issue is: - don't encourage users to work with unavailable drives. Here I completely agree with the second one comment about Favourites tab that should use file chooser and just keep user favourite links. Then probably DataObject for A: won't be ever created which is super because then OperationListeners won't be notified about creation. I see OperationListener.operationPostCreate like a good way how to distribute this problem. - if there is code that access unavailable drives then we should consider it as a bug I believe that with David hotfix is everything OK and if there occures some problem then must be fixed. Everybody must be carefull if works with File ("A:") and the same must be true for FileObject that represents it. Moreover I like David's hotfix because outside userdir shouldn't probably go no Netbeans meta data files (.nbattrs , shadows, instance, settings).
I decided to deprecate usage of DataShadow on non-DefaultFS and leave the fix done in this issue as is. I filed issue 43525 for myself to do that. The reason is that DataShadow should not be needed anymore on client FS and new features like Favorites View should not be based on something what we plan to deprecate/redesign. So, PetrN, please use non-DS based solution. It might be even easier. The original problem filed in this issue was fixed. Re. discussions between Jesse and Radek: file separate issue if needed. Thx.
I tried to filter floppy drives and empty CD-ROMs in MasterFS. Seems to be OK but if you are on Windows please test it. /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/SpecialDelegates.java new revision: 1.7; previous revision: 1.6
Seems to work fine in recent trunk and refactoring builds. Floppy and empty CD drives are filtered.
I believe that the fix is not correct as it causes issue 44894 which imho can influence correct work of favourites tab.
the fix may cause another bug, but this one is fixed. Please keep it so.
I had this problem recently with an empty CD ROM drive (build from August 11). I never accesses the All Files view (what is that anyway) but there was a CD in my driver when I started and closed NB. Then before restarting I removed the CD and the errors came. This was also after using a new build: running build from August 5th, CD in drive e:, closed NB, installed new build, removed CD, started new build -> "There is no disk in drive e:" It seems that somehow NB stores which drives it could access the last time (note that I never had the problem with drive a: my floppy disk) and tries to access it the next time.
As I already suggested on nbusers, next time you see it, please capture a thread dump (before closing the error dialog) and attach it to this bug report. Thanks.
Haven't seen it since the last check. Verified.