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 compiling with target directory after restarting NB, this exception occurs. a) with local file; Fatal error: Target filesystem is invalid. Errors compiling CatchString [Local]. and b) with file under CVS working directory; Fatal error: Target filesystem is invalid. Errors compiling HtmlEntityKeyServlet [Locally Modified; 1.7]. Both files in examples were compiled to target directory prior restarting NB. When this occurs the 'Default' project in target shows <invalid target>. From then on, when target directory set, it does not work, compiled .class files go to source directory. Could this please be corrected. Kind regards Emmanuel
Created attachment 2397 [details] ide log
Created attachment 2398 [details] ide log
Created attachment 2399 [details] Target directory in default project
Created attachment 2400 [details] userdir zip file
Moving to java. Emmanuael, do you remember to what filesystem did you direct the compiler output before the bug occured ? Was the filesystem mounted and accessible at the time the IDE started to show "target invalid" ?
Hello Svatopuk, <Emmanuael, do you remember to what filesystem did you direct the compiler output before the bug occured ? I was working in the res (or Research) project, where I set a target directory and yes the filesystem was mounted, viz., f:\docs\deploy\com\lifecanbedifferent\web\rsch\web-inf\classes <Was the filesystem mounted and accessible at the time the IDE started to show "target invalid" ? Yes, the filesystem was mounted when the ide started (in the res project), the filesystem was visible - I did not manipulate any files so apart from being visible I do not know how accessible it was within the ide. But please bear in mind, the <invalid target> appeared in the default project – not the project I was working in, and in the default project the target directory is not mounted. I noticed the <invalid target> in the default project purely incidentally because of swapping projects around to determine what was happening. Svatopuk, another point though, with the project settings being replaced by the tools->setting for target directory, would each project be able to have it’s separate target directory? Kind regards Emmanuel
No, specifying "target" property in a compiler type, or creating a new compiler type, will (or should) write the compiler type definition to the project layer. So the modified compiler should not be visible outside the project where it was created at all!
I found even with 20010831-qbe1, that target directory does not persist per project. Whatever I specify in a project, say project xyz, is also the target in the default project where it was never specified, then when correcting it in the default project, by stipulating it as not set, then in project xyz, where target was set, before switching projects, it is then also not set. Hope this helps. Kind regards Emmanuel
Seems to be fixed in build 09/12/2001. Please try to verify it in Q-build from 09/07/2001 or the next Q- or Beta- build. When you will set the target directory, pay attention to the layer the compiler will move into. It should be defined in the project layer - if it is marked on the "user" layer, then the setting is shared among all projects within the given user directory.
Hello Svatopuk. I used 0907-qbe2 & 0912 and this does not work yet. As a result, I feel this needs to be reopened. BTW, when it worked for you, did you switch projects back and forth and restart NB and so forth - and compiled inbetween? This is what I still get in 0907-qbe2; a) **target is set for project** Fatal error: Target filesystem is invalid. Errors compiling CatchStringBPoint [Local]. b) **target is not set for project** Fatal error: Filesystem F:\Docs\DEPLOY\com\lifecanbedifferent\web\rsch\WEB-INF\classes is not mounted in Filesystems. Errors compiling TestPol_3. Notes; - I have the target set at the project level, - every now-and-then, I still get <invalid target>, - restarted NB and error in b) above disappeared. Something is definitely still amiss. Over to you. Kind regards Emmanuel
Emmanuel, sorry to bother you further, but in order to eliminate existing setup issues and to get me as close to the situation, could you please try to reproduce the bug starting from a fresh clean nbuser directory ? Just pass parameter -nbuser some-other-directory to NetBeans' executable to preserve your existing configuration. I'll be then able to repeat the steps and probably get to the root cause. Please reopen the bug, too. BTW I finally corrected the typo in my issuezilla user registration ;-) thanks.
Hello Svatopuk, <Emmanuel, sorry to bother you further, but in order to eliminate <existing setup issues and to get me as close to the situation, could <you please try to reproduce the bug starting from a fresh clean <nbuser directory ? Absolutely no problem and thank you for your support. Will do, this evening, currently at work. Since from which build is change affected? >Just pass parameter -nbuser some-other-directory to NetBeans' >executable to preserve your existing configuration. I'll be then >able to repeat the steps and probably get to the root cause. Will do. >Please reopen the bug, too. Based on my experiences and having read on mailing lists, many people use this feature. It is probably higher than P2. Kind regards Emmanuel
0913 freezes so I cannot get anything done.
Hello Svatopuk, This took me forever to pinpoint. Here goes. With build 0913, steps to reproduce; 1. clean userdir, 2. on startup NB creates project Default, 3. create project Abc, with; 3.a) mount source directory as CVS working directory, 3.b) mount local directory, say aaa, 3.c) set local directory aaa as target directory, 3.d) compile, switch projects, restart NB, etc., all works 100%, 4. create project Xyz, with; 4.a) mount local directory, say bbb, 4.b) compile, etc.. 5. switch back to project Abc, and notice the following; 5.a) the local directory mounted is bbb, which belongs to project Xyz, however what is supposed to be mounted is, aaa. And no matter what is done, target directory does not work. 6. switch to project Xyz, 7. unmount all (notice what is mounted - supposed to be bbb), 8. switch back to Project Abc, 8.a) ensure that local directory aaa is mounted, ensure target directory is set, viola, target directory works 100% Hope this helps. BTW, I previously said NB freezes up - your suggestion to run with as little switches in ide.cfg assisted me to pinpoint the freeze, thank you. From a point of interest, see http://openide.netbeans.org/issues/show_bug.cgi?id=15533 Kind regards Emmanuel
Please note, another aspect that affect target directory, in addition to previous posting, is the XMLSupportModule.jar.
Posted XMLSupportModule issue, please see; http://openide.netbeans.org/issues/show_bug.cgi?id=15539.
Please see the steps provided near the end of the message. At 3d) I switched back to Default project and saw "<Invalid target>" in Target property of the default compiler. The service type, which was changed in Abc project was persisted into the user layer, not the project-specific one, so it affects all projects. Please reassign back/advise if some action needs to be taken by Java module (like tagging service types as project-local).
Assigning to Honza. Maybe that Honza or Vita will know more. See the latest steps to reproduce.
IMO it is caused by missing mounted filesystem after switching to the project. *** This issue has been marked as a duplicate of 15513 ***
Sorry, the filesystem is *not* lost in this case - if filesystem collection is "local" to a project. To quote myself, "The service type, which was changed in Abc project was persisted into the user layer, not the project-specific one, so it affects all projects." So it is not duplicate of missing / not persisted setting. It is a setting which is stored in an incorrect layer. I asked for advice - whether I need to specifically mark service types local to a project, or if they are local by default.
Svato and Emmanuel sorry for delay. When I've tried to reproduce it the filesystem *was* lost. So I concluded it is caused by #15513. Anyway with latest sources I cannot reproduce it anymore and the copmiler settings are stored to the project layer properly (running with empty nbuser). Regarding specifying target layer. Yes you have to specify project layer using the file attribute SystemFileSystem.layer=project. The external compiler already has this attribute. If you find out the problem remains please reopen the bug again. Thanks.
Yes, it works (at least when the steps are followed). Nothing unusual (or unexpected) happened and options looks after switching projects. Emmanuel, could you verify that ?
Hello Jan & Svatopuk, Using 0925, and I still get <invalid target> where target is set. See attached jpg. Then with the project where target <not set>, this is what I get when compiling; Fatal error: Target filesystem is invalid. Errors compiling Test6_Inheritance. Don't know what to say further - I'm hoping this is not the build where the correction was applied - please advise from which build! Thus I'm still getting exactly as per posting on 2001-09-12 17:34. Over to you. Kind regards Emmanuel
Created attachment 2692 [details] options showing <invalid target>
I'm attaching the ide.log, it contains numerous exceptions, which might be related.
Created attachment 2693 [details] ide log
Reopening; incorrect behaviour confirmed.
Moving back to java -- user directory seems to be OK, settings placement is correct so core is innocent IMO. Thanks, Honza & Vita.
Some behavior I observed - still with build 0925 & jdk1.3; When restarting NB all is ok for project at startup, then when switching projects, it plays up, then restart NB and all is again ok for project at startup. This applies, to where target <set> and where target <not set>.
Finally got it (for the third time ?). It's a race condition between restoring filesystems and serialized compiler types. I cannot debug it (since timing changes), but System.err.println() worked.
Commiting without confirmation from the reporter; need to catch up with Q-build deadline. Supposedly fixed in trunk (JavaCompilerType, rev. 1.29)
[200109270100] Although I cannot reproduce <invalid target>, I have to reopen this issue, because target filesystem is not remembered, when switching between project. Try to set the target filesystem and then switch to different project and then back again.
in jdk1.4 the target is forgotten the moment you switch to another node in the options menu or exit options. :(
Can't reproduce (10/17/2001)
Since beta 5 I have been getting this very frequently. The compile target becomes invalid and I have to reselect it. I have not been able to test with beta 6 yet since the download link is broken. I am not sure what information I can provide to help diagnose this but here is some info: 1) Did not happen on beta 4 2) I am not restarting the IDE or switching projects 3) No exceptions in the log Any ideas what beta 5 change could have caused this?
I am sorry but playing with build # 200111271845 (beta6) I cannot reproduce the behaviour. Any 'meaningless' clue will be appreciated. Thanks.
I cannot reproduce this bug in [200111300330]. Robert, if you have some scenario, how to reproduce this bug, please reopen the issue. Thanks
I can confirm that this bug still exists in 3.3.2 RC2. I have a number of projects where the source is located in a CVS repository using a local working directory. They are all compiled to a local directory. (Though when I say local I really mean NFS mounted). If I set a target for external compilation in a project, change to another project, and then change back to the original project, the compilation target is frequently set to <invalid target>. It does not seem to matter whether it is set as a project settings level or session (user) settings level. I am using Mandrake Linux 8.2, however a collegue also experiences this bug on his Windows NT workstation using the same project setup.
I was playing with this issue for an hour and finally I found reproducible test case: Steps to reproduce: 1. Create new project P1 2. Mount many filesystems (~10) 3. Set target property for external compilation 4. Create new project P2 5. Mount many filesystems (~10) 6. Set target property for external compilation 7. Switch to P1 8. Target property of external compilation can be invalid I think, that this is not P2 issue. There is no data loss and a workaround exists (user can set the property again). Problem may be in project switching. It looks like the compiler settings are initialized before all filesystems are mounted.
Reproducible in 3.3.1 and 3.4
Listening on filesystem mount/unmout events fixed. Target filesystem setting invalidates when filesystem is unmounted and is turn to valid one when same filesystem is mounted again. This should fix problem with project switching.
VERIFIED in 200206260100
Resolved for 3.4.x or earlier, no new info since then -> closing.