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 26521 - get same exception 9 times when mounting root directory
Summary: get same exception 9 times when mounting root directory
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 3.x
Hardware: Sun SunOS
: P2 blocker (vote)
Assignee: _ pkuzel
URL:
Keywords:
Depends on:
Blocks: 26495
  Show dependency tree
 
Reported: 2002-08-14 22:11 UTC by George Hernandez
Modified: 2008-12-22 23:08 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Hernandez 2002-08-14 22:11:20 UTC
I'm using the current netbeans development sources
that I updated today and j2sdk 1.4.0 on a sun
blade 100 running Solaris 8.

When I mount the root directory in the explorer, I
get the same exception 9 times for each file that
is either a nonexistant file or is unreadable (no
read permissions). These and other messages grew
my ide.log file to over 2.4 Mbytes.

INFORMATIONAL *********** Exception occurred
************ at Wed Aug 14 13:34:47 PDT 2002
Annotation: File not found. Another application
may have moved the file or changed the name.
java.io.FileNotFoundException:
/cvstree/orionfcs/regress (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at
java.io.FileInputStream.<init>(FileInputStream.java:103)
	at
org.openide.filesystems.LocalFileSystem.inputStream(LocalFileSystem.java:412)
	at
org.openide.filesystems.LocalFileSystem$Impl.inputStream(LocalFileSystem.java:628)
	at
org.openide.filesystems.AbstractFileObject.getInputStream(AbstractFileObject.java:165)
	at
org.openide.filesystems.MIMESupport$CachedFileObject.getInputStream(MIMESupport.java:169)
	at
org.netbeans.core.filesystems.MIMEResolverImpl$Type.accept(Unknown
Source)
[catch] at
org.netbeans.core.filesystems.MIMEResolverImpl$Type.access$1500(Unknown
Source)
	at
org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.resolve(Unknown
Source)
	at
org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.access$000(Unknown
Source)
	at
org.netbeans.core.filesystems.MIMEResolverImpl$Impl.findMIMEType(Unknown
Source)
	at
org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:152)
	at
org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:142)
	at
org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:55)
	at
org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:601)
	at
org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:147)
	at
org.openide.loaders.ExtensionList.isRegistered(ExtensionList.java:134)
	at
org.openide.loaders.UniFileLoader.findPrimaryFile(UniFileLoader.java:62)
	at
org.apache.tools.ant.module.loader.AntProjectDataLoader.findPrimaryFile(Unknown
Source)
	at
org.openide.loaders.MultiFileLoader.findPrimaryFileImpl(MultiFileLoader.java:232)
	at
org.openide.loaders.MultiFileLoader.handleFindDataObject(MultiFileLoader.java:65)
	at
org.openide.loaders.DataLoader.findDataObject(DataLoader.java:221)
	at
org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:365)
	at
org.openide.loaders.FolderList.createBoth(Unknown
Source)
	at
org.openide.loaders.FolderList.getObjects(Unknown
Source)
	at
org.openide.loaders.FolderList.access$200(Unknown
Source)
	at
org.openide.loaders.FolderList$ListTask.run(Unknown
Source)
	at org.openide.util.Task.run(Task.java:136)
	at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599)
Comment 1 George Hernandez 2002-08-14 22:31:40 UTC
Changing the priority to p2 since this enlarges the ide log tremendously.
Comment 2 _ ttran 2002-08-15 12:27:47 UTC
"current netbeans development sources" means "4.0 dev".  Next time
please set the "version" field correctly, don't use "current".

Eval: the MIME resolver needs to read the file, if the user does not
have read permission this will fail.  Filesystem must consider such
situations and react appropriately.
Comment 3 rmatous 2002-08-23 09:20:47 UTC
According to stacktrace I think that can be handled in
org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.resolve 
where ErrorManager.notify is called. Anything like 
if (FileUtil.toFile (fo).canRead ()) ErrorManager.notify(...);
else return null;

Petr please investigate.
Comment 4 _ pkuzel 2002-08-23 11:17:08 UTC
Yes, such check can be added, but it is LocalFileSystem specifics. I
would prefer FileObject's method. Can I use isValid() for this
purpose. Is FileObject representing unreadable File valid?
Comment 5 rmatous 2002-08-23 12:44:49 UTC
isValid isn`t definitely suitable for this purpose.  Unreadable
FileObject can be valid (why not ?). I think there is no suitable 
method in FileObject at all. Moreover I think that this problem is
really LFS and CVS specific, so also solution can be easily LFS and
CVS specific.  

If no objections I`ll fix it according to my previous comment.
Comment 6 _ pkuzel 2002-08-23 13:54:04 UTC
I see, FileObject.isValid() is defines deserialization status.

My concern is that now we should scan all sources and apply the patch
almost everywhere. FileObject.isValid() is called with similar intent
now i.e. to predict if operations will fail.
Comment 7 Torbjorn Norbye 2002-08-23 18:13:37 UTC
The issue here is one of file permissions. You can see
a file, but you don't have permission to read it. 
That's a more general concept than "LFS" or "CVS" I think;
I can easily imagine a different kind of filesystem which
also supports file permission.  I think a better solution
would be one where you can test to see if a file supports
reading or writing; FileObject.isReadable(). (Or perhaps
it should just return null instead of an input stream
when you ask for one to indicate that you can't read from
it.)
Comment 8 rmatous 2002-08-26 09:40:27 UTC
I can add method and change API, but I`m not 100% sure that it is
necessary. I would not like to see calling of isReadable before every
getInputStream call. Moreover between isReadable  call and
getInputStream can be file permission changed externally and
asynchronously. FileSystem implementations could easily return empty
inputStream, which can be often good enough.  

What about to throw appropriate subclass of IOException. Perhaps
java.rmi.AccessException ?  
Comment 9 rmatous 2003-01-08 14:55:22 UTC
Merkde as duplicate: #28844

*** This issue has been marked as a duplicate of 28844 ***
Comment 10 _ gordonp 2003-01-08 16:42:55 UTC
I strongly dissagree with closing this issue as a
duplicate of 28844. This issue has nothing to do with
a source editor OR .class files, both of which are
part of 28844. In addition, this issue is a P2 and
blocks 26495.

The real underlying problem here is that the Explorer
generates numerous exceptions, while trying to gather
enough information to determine what type of DataObject to create for
a FileObject, if the file associated with the FileObject cannot be read.

This issue will also become important in future releases if netbeans
starts mounting "/" by default.
Its very likely unreadable files and directories will be found in that
case. Since none of this has anything to do with a class file being
deleted for an
open java file this isn't a duplicat of 28844.
Comment 11 rmatous 2003-01-08 17:49:09 UTC
First I thought, that I misstyped bug number. But now I must insist
that bugs  #26521 and #28844 are identical, attached stacktraces are
also identical. Maybe that I should administratively mark duplicate
vice versa and let in IZ bug with higher priority.  

Please Petr evaluate if you really need method isReadable to fix this
issue. I have nothing against such method, but see my previous
comments... Moreover I would prefer to have pair of method: canRead,
canWrite (or isWritable, isReadble) instead of isReadOnly, isReadable.
So, then I would suggest to deprecate method isReadOnly and introduce
new pair of methods.
Comment 12 ivan 2003-01-08 20:03:45 UTC
Some additional comments.
- I ran into this with stale soft links in my ~/bin. Same story,
  lots of exceptions.
- Using isValid() or any predicate is nuts! The whole _point_
  of exceptions is that you don't do tests before attemtps.
  If you do get an exception, _then_ you go find out what was 
  wrong with what you tried to open.
  There's also probably the matter of efficiency. Predicated will 
  probably do a 'stat()' on the file, which maps the filename to a 
  aninode. Thenopen will have to do the same. If youhave lots of files
  this will all add up.
- finally, I thought that it is customary to make _newer_
  issues closed as duplicated of _older_ issues. This issue has had
  a fairt amount of discussion in it already, but by marking it a 
  dup of #28844, which doesn't have that much info in it, the taril
  of discussion might be lost unto other people.

Comment 13 _ pkuzel 2003-01-09 09:37:21 UTC
See nice Ivan's comment on predicates. I must agree. Please introduce
such methods.
Comment 14 rmatous 2003-01-10 15:28:07 UTC
API changes in trunk: openide-spec-version 3.31.
Reassigned to pkuzel.

/cvs/openide/openide-spec-vers.properties,v  <-- 
openide-spec-vers.properties
new revision: 1.96; previous revision: 1.95

/cvs/openide/api/doc/changes/apichanges.xml,v  <--  apichanges.xml
new revision: 1.128; previous revision: 1.127

/cvs/openide/src/org/openide/filesystems/FileObject.java,v  <-- 
FileObject.java
new revision: 1.72; previous revision: 1.71

/cvs/openide/src/org/openide/filesystems/AbstractFileObject.java,v 
<--  AbstractFileObject.java
new revision: 1.81; previous revision: 1.80

/cvs/openide/src/org/openide/filesystems/AbstractFileSystem.java,v 
<--  AbstractFileSystem.java
new revision: 1.51; previous revision: 1.50
Comment 15 _ pkuzel 2003-01-17 13:01:35 UTC
I plan to return silently "application/unknown" to handle this case.
Any comments?
Comment 16 _ ttran 2003-01-29 13:38:19 UTC
pkuzel and others: what is the status of this bug?
Comment 17 _ pkuzel 2003-01-29 16:11:00 UTC
I'm going to integrate it....
Comment 18 _ pkuzel 2003-01-29 16:30:11 UTC
MIMEResolverImpl.java
new revision: 1.9
Comment 19 pzajac 2003-03-12 12:05:53 UTC
[2003031223500] verirfied