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 43315 - Frequent 'No disk in drive A' errors
Summary: Frequent 'No disk in drive A' errors
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P1 blocker (vote)
Assignee: David Konecny
URL:
Keywords: T9Y
Depends on: 44894
Blocks:
  Show dependency tree
 
Reported: 2004-05-15 20:40 UTC by Jan Chalupa
Modified: 2008-12-22 19:44 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
A screen shot with the error message. AWT blocked. (23.56 KB, image/png)
2004-05-15 20:40 UTC, Jan Chalupa
Details
Thread dump when blocked. (11.91 KB, text/plain)
2004-05-15 20:51 UTC, Jan Chalupa
Details
Thread dump (14.16 KB, text/plain)
2004-05-17 10:56 UTC, Jan Chalupa
Details
Another thread dump (11.19 KB, text/plain)
2004-05-17 14:14 UTC, Jan Chalupa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Chalupa 2004-05-15 20:40:04 UTC
[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).
Comment 1 Jan Chalupa 2004-05-15 20:40:56 UTC
Created attachment 14883 [details]
A screen shot with the error message. AWT blocked.
Comment 2 Jan Chalupa 2004-05-15 20:47:27 UTC
Found it. See issue #23725.

Forgot to mention that A: is a floppy drive on my Win XP box.
Comment 3 Jan Chalupa 2004-05-15 20:51:32 UTC
Created attachment 14884 [details]
Thread dump when blocked.
Comment 4 Jesse Glick 2004-05-16 02:04:57 UTC
Probably a masterfs issue.
Comment 5 rmatous 2004-05-17 08:11:34 UTC
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.

Comment 6 rmatous 2004-05-17 08:56:23 UTC
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.
Comment 7 Jan Chalupa 2004-05-17 09:10:33 UTC
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.
Comment 8 Jan Chalupa 2004-05-17 09:12:12 UTC
Needless to say I have never created any projects on a floppy drive.
Comment 9 rmatous 2004-05-17 09:27:01 UTC
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. 
Comment 10 Jan Chalupa 2004-05-17 10:56:05 UTC
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)
 
Comment 11 Jan Chalupa 2004-05-17 10:56:52 UTC
Created attachment 14904 [details]
Thread dump
Comment 12 rmatous 2004-05-17 11:49:38 UTC
David, can you explain why there exist DataShadow on something in
drive A: ?
Comment 13 David Konecny 2004-05-17 12:08:22 UTC
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.
Comment 14 Jan Chalupa 2004-05-17 14:13:45 UTC
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.
Comment 15 Jan Chalupa 2004-05-17 14:14:33 UTC
Created attachment 14909 [details]
Another thread dump
Comment 16 Jan Chalupa 2004-05-17 14:19:34 UTC
Reproducible with a clean userdir without opening any projects. Steps
1-3 can be safely skipped.
Comment 17 Jan Chalupa 2004-05-17 14:21:21 UTC
Dtto w/ JDK 1.4.2.
Comment 18 David Konecny 2004-05-17 15:34:03 UTC
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.
Comment 19 David Konecny 2004-05-17 16:31:51 UTC
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? 
Comment 20 Jesse Glick 2004-05-17 17:19:08 UTC
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.
Comment 21 Jan Chalupa 2004-05-17 17:26:28 UTC
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.
Comment 22 rmatous 2004-05-17 17:58:48 UTC
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:. 
Comment 23 Jesse Glick 2004-05-17 18:10:35 UTC
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.
Comment 24 Jesse Glick 2004-05-17 18:22:58 UTC
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.
Comment 25 rmatous 2004-05-18 10:15:14 UTC
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).

Comment 26 David Konecny 2004-05-19 10:32:33 UTC
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.
Comment 27 rmatous 2004-05-19 16:22:22 UTC
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
Comment 28 Jan Chalupa 2004-05-22 17:27:03 UTC
Seems to work fine in recent trunk and refactoring builds. Floppy 
and empty CD drives are filtered.
Comment 29 Jaroslav Tulach 2004-07-03 19:24:12 UTC
I believe that the fix is not correct as it causes issue 44894 which
imho can influence correct work of favourites tab.
Comment 30 _ ttran 2004-07-04 00:15:12 UTC
the fix may cause another bug, but this one is fixed.  Please keep it
so.  
Comment 31 tkellerer 2004-08-13 16:02:34 UTC
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. 

Comment 32 Jan Chalupa 2004-08-13 16:11:01 UTC
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.
Comment 33 Jan Chalupa 2004-10-15 21:36:36 UTC
Haven't seen it since the last check. Verified.