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.
Summary: | Don't use relative paths for files accessed through absolute path | ||
---|---|---|---|
Product: | projects | Reporter: | Torbjorn Norbye <tor> |
Component: | Generic Infrastructure | Assignee: | issues@projects <issues> |
Status: | CLOSED FIXED | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 25661 | ||
Bug Blocks: |
Description
Torbjorn Norbye
2002-09-30 21:44:08 UTC
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 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. |