Apache OpenOffice (AOO) Bugzilla – Issue 83580
Debug Extension creates files owned by nobody
Last modified: 2013-02-24 20:55:00 UTC
My desktop description - Windows Vista - OpenOffice.org 2.2.1 & SDK - NetBeans integration module ( OpenOffice.org API Plug-in version 1.1.0 ) - NetBeans 5.5.1 There's no problem in Deploy OpenOffice.org Extension, Deploy and Run Extension in OpenOffice.org and Create OXT. It works perfectly. But when I select Debug Extension in Target OpenOffice.org, it behaves differently. Here are my steps ... 1. Click on Debug Extension in Target OpenOffice.org 2. Strange thing - OpenOffice.org registration dialog appears ( like first time start ) 3. OpenOffice.org is running with my extension, debugging session in NetBeans 4. Quit OpenOffice.org 5. Stop debugging session in NetBeans 6. Clean & Build project - failed Debugging session creates lot of files under build/soffice_debug directory. Some of these files are owned by nobody. Windows Vista have no idea who owns these files and I can't take ownership and I can't delete them easily even as administrator. I found a way how to delete them - kill explorer.exe, logout & login, take ownership and delete. No other way how to delete them. Restart, nothing helps. Can debugging session use my current OpenOffice.org configuration? Start OpenOffice.org like "Deploy and Run ..."?
Well, this was thought of as a feature: for debugging purposes, the plugin forces the office to create a new user installation in your project/build directory. This is, because an extension in testing phase may well corrupt your user installation and - in the worst case - force you to delete it. At least it may create a bit of work removing it, and with the user installation in the build directory, you just clean your project and can start anew. I have no experience with Windows Vista, though. My first guess is that it's a problem of OpenOffice.org regarding the creation of the new user installation. If you really want to use the existing user installation, you have to do this: - open the file <your_project>/nbproject/build-uno-impl.xml - go to the bottom of the file to the target with the name "uno-debug" - remove all lines <env key="UserInstallation" value="${office.debug.user.directory}"/> Without the line, no new user installation is created. Notice that it's there twice, once for the unopk command and once for starting OpenOffice.org. Caution: build-uno-impl.xml is not for editing, normally. When updating the OpenOffice.org API plugin, the file may be overwritten. If you have some knowledge of Ant, you may overwrite the target in the build.xml file. I have not tested this, though. And lastly, I will look into the Windows Vista problem asap.
Thanks for the hint. If you need more info from me, or some tests, just let me know. It is easily reproducible, or at least on my machine.
I am not the Windows Vista expert, but I talked to one ;-), and have a question. There may be some problems on Vista due to the virtual folders it creates. This is bound to happen in system folders. Does your project reside somewhere in "c:\user" or "c:\program"? If yes, do you still have problems if you move the project into a self-created top level folder?
My projects are in ${USER-DOCUMENTS}/NetBeansProjects directory. I moved (*) ${USER-DOCUMENTS} from C:\User ... to D:\Dokumenty. So, projects are in D:\Dokumenty\NetBeansProjects directory. (*) Moved means, that I copy all files to this new location and I modified Windows Vista settings, do 'Documents' folder points to this location. Whole disk D: is owned by my user and I changed permissions to take full control of this disk. From this point of view, there are no virtual folders on this disk. But what I can try is to move NetBeansProjects directory from D:\Dokumenty to D:\. I'm going to try it now ...
Hmm, this is really interesting. When my 'NetBeansProjects' directory resides in user's document directory (doesn't depend if this is in under C:\User, D:\whatever, ...), it doesn't work. Files owned by unknown are created. When I move 'NetBeansProjects' directory outside any of these "system" (or virtual) folders, everything works perfectly. So, it is enough to move NetBeansProjects directory outside virtual folders. Works for me, it's a Vista problem. Thanks for your time.
I will keep the bug with target 3.x, this may be solved in OpenOffice.org and/or NetBeans.