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.
One thing that must be checked in order for AU to work on Windows when updating core.nbm is that runide.exe and/or updater.jar might be upgraded in a new core.nbm (installed in global mode). While the updater is running, it is likely that these two files (and maybe a couple others like ide.cfg?) will have Windows file locks on them, preventing them from being overwritten. 1. If the file contents have not changed, the updater should do nothing, and avoid a lock error. 2. If the file contents *have* changed, it will need to figure out something else. Either refuse the update, try to launch a new process to do it and exit the current process, ask the user to do the final step by hand, etc.
updater.jar is updated when updating AU module itself, which is also not possible on Windows
1. runide.exe - more difficult, CCing Trung as launcher maintainer 2. updater.jar is other problem. (as Maxym mentioned it's part of autoupdate.nbm, not core) In that case (windows && autoupdate.nbm && updater changed) I can: - Replace updater.jar at the end of AU wizard = *before* updater will be started. It can be possible, because updater is independend on other parts of IDE. All update will be done via *new* updater. I prefer this way. or - copy it somewhere and let launcher to replace it after finishing updater. All update will be done via *old* updater.
I'm pro the first method, the updater.jar should be replaced when user clicks OK in the final window ("Restart needed"). >- Replace updater.jar at the end of AU wizard = *before* > updater will be started. It can be possible, because > updater is independend on other parts of IDE. All update > will be done via *new* updater. I prefer this way.
First method for updater.jar sounds best too. Still left with a problem for updating runide.exe. It runs both the IDE and the updater and will be locked the whole time.
Strange, I tried to install autoupdate.nbm (on my Win2K) with changed updater.jar and I have no problems! Dont know why, but it works :-) Does somebody know, in which configuration it doesn't work?
Nope, I was just guessing that it would not work, based on problems I've had with similar situations...never tried it.
Created attachment 6111 [details] updater.jar
Sorry, I attached this jar by mistake - it should be attached to other issue :-)
Fine, it looks like we can close updater part. ----------------------------- Trung, what about runide.exe? I can in (AU wizard) detect that runide.exe should be updated and e.g. write this information to some file.. Could launcher in such special case run updater in extra JVM and just exit?
Windows locks all .exe files (and .dlls, etc.) when they are being executed. This means we cannot replace runide{,w}.exe. Using java.exe to run the updater in special case does not work because there must be a parent runide.exe somewhere anyway. One possible solution is: runide.exe checks for any runide_?.exe in the same directory (for example runide_1.exe) and if the latter is newer than the former then the latter is exec'ed in place of the former. NT Emacs port does this. However I am not sure if we really want to go that far. For now I would be satisfied with the fact that runide.exe is not auto-updateable. We don't support runide.exe in userdir anyway.
I know runide.exe is not supported in the userdir - in fact AU will only permit core.nbm to be unpacked in the install dir. But *something* needs to be fixed: at least my #1 - if file contents have not changed, do not try to unpack. Currently even with an unchanged runide.exe you will (I guess) get an IOException unpacking.
#1 works now, so I'm changing this to ENHANCEMENT to somehow implement replacing runide.exe
Target milestone was changed from '3.4' to TBD.
*** Issue 26830 has been marked as a duplicate of this issue. ***
reassigne to Hrebejk, new owner of autupdate
reassigne to Jirka - new owner of autoupdate
It seems there is comming a way for us how to build our own launchers (CC'in Yarda). Removing the status whiteboard 'keyword'.
Btw. I'd like to note that it is possible to overwrite .exe files on windows I just did from module install: File f = ".../lib/nbexec.exe" f.renameTo(new File(f.getParentFile(), "nbexec.old"); and now one can write to the file f. I propose to improve AutoUpdate updater to check for situations when it cannot overwrite some file and if on windows, then try to rename it, delete on exit and write to the original file which is going to be open for overwriting.
Huh, nice trick. Basically moving the inode. Can you move to ${java.io.tmpdir}? I guess you have to take care that it is on the same drive?
autoupdate/test/unit/src/org/netbeans/modules/autoupdate/ has been branched to nbexec_24361 and contains a test to simulate the problem.
I just want to confirm that this issue is still valid. It is possible to update launcher on unix system but on windows it throws the following exception: java.io.FileNotFoundException: D:\build\60\beta2\1018\netbeans\platform7\lib\nbexec.exe (The process cannot access the file because it is being used by another process) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:179) at java.io.FileOutputStream.<init>(FileOutputStream.java:131) at org.netbeans.updater.ModuleUpdater.unpack(ModuleUpdater.java:370) at org.netbeans.updater.ModuleUpdater.run(ModuleUpdater.java:126)
Tag: nbexec_24361 User: jrechtacek Date: 2007/10/25 01:42:34 Modified: autoupdate/services/libsrc/org/netbeans/updater/ModuleUpdater.java Log: a failed code The trick haven't worked for me. I'll debugging it later, the best is get it for NB6.
Fixed: autoupdate/services/libsrc/org/netbeans/updater/ModuleUpdater.java 1.16
Verified. It is really working now.