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.
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)
Changing the priority to p2 since this enlarges the ide log tremendously.
"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.
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.
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?
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.
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.
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.)
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 ?
Merkde as duplicate: #28844 *** This issue has been marked as a duplicate of 28844 ***
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.
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.
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.
See nice Ivan's comment on predicates. I must agree. Please introduce such methods.
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
I plan to return silently "application/unknown" to handle this case. Any comments?
pkuzel and others: what is the status of this bug?
I'm going to integrate it....
MIMEResolverImpl.java new revision: 1.9
[2003031223500] verirfied