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.
When opening my project, I got an exception like this: Annotation: org.netbeans.modules.settings.InstanceProvider@21ad24[org.openide.loaders.InstanceDataObject@6e2194[Structure/sources/link_2.settings], xml/lookups/NetBeans/DTD_SimpleLink_1_0.instance] java.net.MalformedURLException: cannot resolve: nbprjres://project/ProjectFilePosition/../../../../odin/projects/nb_all/projects/src/ProjectTasks.ics at org.netbeans.modules.projects.DefaultContainer$SimpleLinkConvertor.read(DefaultContainer.java:628) at org.netbeans.modules.settings.InstanceProvider$InstanceCookieImpl.instanceCreate(InstanceProvider.java:255) [catch] at org.netbeans.modules.projects.DefaultContainer.scanStructure(DefaultContainer.java:205) at org.netbeans.modules.projects.DefaultContainer.scanStructure(DefaultContainer.java:194) at org.netbeans.modules.projects.DefaultContainer.access$100(DefaultContainer.java:61) at org.netbeans.modules.projects.DefaultContainer$1.run(DefaultContainer.java:120) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599) Notice how it's looking for a path by relative name: nbprjres://project/ProjectFilePosition/../../../../odin/projects/nb_all/projects/src/ProjectTasks.ics I'm not sure why it couldn't find the relative file (I haven't moved or renamed anything) but my guess would be that it happened because I opened this project explicitly (through the Open action on the projects node) and had to locate the project file; since I knew that it was closest to /home/tor (as opposed to the other mounted file system, /) I used /home/tor. Perhaps the relative paths break down when using different filesystems like this. However, the path to this file is :/odin/projects/... . Note that even though the file is available from root, it's trying to make it relative. I think that once you've backed up to the root of a file system, you should drop the "relative" portion and just make it an absolute path. In fact I don't think it's useful to check too many directories up for relativeness; I find it unlikely that you'll bury the project file deep into your logical project source tree. Perhaps we should only check say three levels - ../../.. ? Or perhaps simply ask the user when adding a new file to the project: this file is not in the same directory or a subdirectory of the location of the project file. Do you want its location to be recorded as relative to the project file or as an absolute path? Those are some possibilities, but at a minimum the failure to find the file should be handled more gracefully - no exception.
I noticed one more thing. I went to check that the path is wrong - and it's actually right; from the project file's location the file DOES exist.So the key is the MalformedURLException part of the stacktrace.
This one is bothering me so I'm going to look into it.
Aha! The problem seems to be in ProjectResolver.Relative. In its resolveRelativeName() method, it walks back up the relative reference, removing each occurrence of "../" and going to the parent file object. In my case, the path is {projectfile}../../../../odin/projects/ The base (the location of the project file) is /home/tor/projects/myproj/. NetBeans now mounts both "/" and "/home/tor". The problem is that it's using a FileObject for base residing in "/home/tor". Thus, after removing "../../" it has gotten to the root file object in "/home/tor" !! The next "../" means that base.getParent() returns null! It should be walking up the "/" filesystem instead, but how exactly do we generalize this? I filed a bug a while back that there should not be two file objects for the same file; http://www.netbeans.org/issues/show_bug.cgi?id=25661 the solution means that the /home/tor/ fileobject will reside inside the / file system (so filesystems will delegate or contain in some way). Hopefully, getParent() on a file object once you get to one of these roots will do the Right Thing(tm). But for now, perhaps I can hack around this by searching for other file systems which can handle the filename once we get to the root.
I have fixed the resolver now such that when it is trying to follow a ../ and has reached the top of a file system, it computes the path to the parent (FileUtil.toFile(base).getParentFile() and then finds a FileObject for this (which, if available, will be in a different filesystem; in my case, "/".) This seems to work - I can open my project again without exceptions. I'm going to leave the bug open a little while longer for three reasons: 1) We still need to decide when to create relative paths and when to use absolute paths 2) We need to handle the case where a path cannot be found better (I guess this is where reference points will come in) 3) Perhaps I can remove the parent-null check if core/openide is changed such that getParent() will always walk into a containing file system when one is available.
I think that we should rely on 25661 being fixed rather then the fix that you've putted into relative resolver. Using toFile() is not safe, since it is not guaranteed to work on all filesystems.
Do you mean that I should back out the fix, or simply that the fix should only be viewed as temporary until 25661 is fixed? I was leaning towards the second alternative (because without the fix I couldn't open my project) but I left the bug open because of it - I don't view the bug "really" fixed yet.
ok, I agree with you.
When 25661 is fixed back out the code in ProjectResolver.Relative.
I am closing this as it's fixed now: - the localfs module is used by new projects, so that there is exact 1:1 mapping between FileObjects and java.io.Files accessible on the machine - the resolver uses relative path _only_ for files which live under the refernce point (no ${ref_point}../../whatever URLs anymore) - the uispec describes how to allow user to make her project 'portable' (how to show files which don't belong to any reference point, allow to manage ref. points, etc. There are separate tasks filed to implement this UI machinery.
Verified
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as CLOSED.