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.
My home dir resides on an NFS server as /net/home/me. For legacy (and partially convenience) reasons, we have a symlink: /home -> /net/home So, my home dir ("me") is accessible via two routes: /net/home/me and /home/me This can confuse NB: If I "Open project with existing <whatever>" and use the symlinked version, then NB thinks there are really two files: /net/home/me/myprojet/myfile and /home/me/myprojet/myfile. Consequences range from irregular CVS ops over not being able to set breakpoints over having the same file opened twice in the editor. This can be massively annoying, hence my initial priority assignment: P2.
Tomasi, Radku, is there anything we could do about it? I don't even know where it should be handled.
Requirement for such implemention in FS library (to have one shared FO for both or more pathes ) was already raised, but it would mean more parents for FO instance and probably also native code would need to be involved. Definitely, can't be solved in 6.0.
Lowering priority since it's special case.
Changing to RFE
(Sorry about the empty post earlier; a click gone astray as my Firefox decided to go all weird on me) Anyway: I don't like what I'm sensing here: Initial report => Lowered priority => RFE => death by obscurity... Now, for any complex problem there's a solution that's simple, elegant -- and wrong! so please bear with me as I speculate about ways of fixing this: The root of the problem seems to be that NB's idea of file identity is based on its path, whatever that path may be made up from -- directories only, or dirs + symlinks. An obvious solution would be to disambiguate all symlinks in a new path. (As an aside, this problem is causing me *deep* annoyance daily, and is actually one of the major things preventing me from recommending NB to my colleagues. It's not reasonable to have them hand-edit configurations.xml whenever NB messes up. "What", you're wondering, "how can it be that bad?" Simple: Each time I add a new file to my project, it gets the wrong path (why? Beats me...) This makes the project non-portable to another user's homedir, because "/home/userid/..." is now prepended to some of the files in the project!)
The idea in FS API is to preserve the submitted path and not to follow(translate) symlinks, because symlinks are very often used to point to a location that is expected to change in time (/home/build_monday, /home/build_tuesday), which isn't intended to be translated and stored persistently. The problem occures when both possible paths are mixed inside IDE, which can happen when: 1/user mixes paths himself when customizing projects, setting userdir, and so on 2/bug somwehere in NB code 1/might be considered RFE (although I don't know much how to simple solve it with current API) 2/is real DEFECT I'm sure that using of symlinks is relatively common in NB IDE and I hope I would have a feedback if it was such a problem. That's why I inclined to mark it as RFE(1/).
I understand your point about why you don't want to store the translated path, and I can accept that; it's a valid use case. However... (couldn't you just feel that 'however' waiting?! ;-) Just to clarify, I have two problems with the current approach: 1. If I have a file stored with a path, /home/me/myfile.cc, then NB doesn't realize that /net/home/me/myfile.cc is the same file. This results in weird stuff like having the same file opened twice in the editor; debugging getting confused; it's a mess. 2. If I try to add a new file to my project (right-click, Add, New C++ file), then I can enter a name, but the path is inconsistent with the rest of the project! All my existing files have no path prefix, but the new file does: It's "/home/me/mynewfile.cc", not just "mynewfile.cc". Remember, my "real" path is /net/home/me, but my NIS entry says /home/me (which is now a symlink; like I said, it's a legacy setup) -- and I guess that's what's tripping up NB (since I've checked configurations.xml and the rest of the files in nbproject dir, and not a single one of them contains "home" anywhere, prior to adding this new file, so where NB gets the /home prefix from is beyond me, unless it gets it from passwd). The solution to this mess, really, would be something along the lines of this: Case 1, not realizing the file is the same: When opening the project: Save the stat() device+inode of each file. Then, when a request for a file comes: stat() the file, look it up in the stat map. Identical => open the original file; no match => open the requested file. Case 2, wrong path prefix: The goal would be to use relative paths if possible, so, for the *project path*, stat() each subdir along the way, from the root. Then, when a new file should be created, stat() it's path. Eliminate common stat() entries from the root up. Then insert "../" for each path element in the original path where there's a difference, and append the unique subpath from the new file. Something like that. Just trying to get the idea across; I haven't tested that this will work in every conceivable way.
Just saw this: * When I add a new file and right-click -> Properties, then it shows up as /home/me/... * When I hover above it in the Project view, it shows /net/home/me/... So, some parts of NB gets it right... ;-)
Reassigning to new module owner jskrivanek.
*** This bug has been marked as a duplicate of bug 182775 ***