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.
Scenario: Having a project folder containing "various" other things (noticed this today with a project that had a shared library descriptor), trying to "delete" the project using the IDE doesn't actually delete the project but keeps these things around on the drive. While not that much a problem in productive use, it starts getting annoying in case of testing projects which start cluttering the hard drive with "partly deleted" fragments. Expected behaviour: Choosing "Delete project" and marking "delete sources from drive" should completely wipe the project folder off the local disk. Maybe for that the "delete sources" option should be renamed to "physically delete..." or something the like to emphasize it's the _full_ project folder (including builds, libraries and virtually any other resources) to be dumped.
What files exactly were left in the project directory? If those files are generated by IDE (e.g. by creating the project), then the bug is valid, but if those files are created by you, IDE won't delete them - IDE deletes only "known" files, all user created files are left untouched.
Most prominent files to remain is the "lib" folder created whenever having a project with "shared libraries" enabled; those are generated by the IDE. About the other aspect however, I'd like then to see this as an enhancement to completely purge _all_ files in a project, no matter whether or not generated by the IDE...
Milosi, please take a look at the lib folder that remains after deleting the project.
well, the lib folder (and the library definitions) could be used by a different project that you are not deleting. The IDE has no way to figure that out. So I'd rather not remove it automatically.
Agreed. Still, having a way to _completely_ purge a project off the drive would be a nice feature. I am uncertain however whether the "delete sources" is or is not the right way or rather making one think of the wrong thing to happen - indeed, actually "delete _sources_" doesn't per se imply configuration files, images and other resources to be deleted as well, but shouldn't it be this way for the sake of clarity? Changing this to an enhancement request...
This happens all the time for me in Web Application projects where if GlassFish is still running there will be a lock on some of the files in the lib\javaee-endorsed-api-6.0 directory (even if the application is undeployed). The main annoyance for me is that the user's expectation (that the project directory will be deleted) differs from the actual behaviour (that some files remain) as when you ask NetBeans to delete the directory there is no feedback that it was unsuccessful. I was thinking that maybe if the directory is targeted for deletion and NetBeans is unable/unwilling to do so, it could display a message like: 1.) If there were locks on files that NetBeans wanted to delete "NetBeans was unable to remove $DIRECTORY from the file system. You will need to remove this directory manually." 2.) If there were user-placed files that NetBeans doesn't want to delete "NetBeans has removed all project-related artefacts from $DIRECTORY. However, there remains additional user-generated files that will need to be removed manually." (Above wording is not ideal, but you get the idea)
Reassigning to default owner.
In some cases projects that normally will delete with deletion of project directory will not fully delete and leave empty folders. For instance, the attached project will not delete fully after doing some operations. 1) Open attached project JEditor.zip. 2) Run Inspect and Transform>>If-Else must use braces. 3) The refactor window comes up - press the Refactor button. 4) When refactor is done - click the Undo button. 5) When Undo is done, delete project and check "Also delete sources under...". Most of the time a few empty directories are left, but sometimes it will completely delete. See attached messages.log file.
Created attachment 119262 [details] Project to use for reproduction.
Created attachment 119263 [details] log file Product Version: NetBeans IDE Dev (Build 201205090400) Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21 System: Windows Vista version 6.0 running on x86; Cp1252; en_US (nb)
I see this is an ENHANCEMENT... maybe this should be filed separately as a bug?
@MackSix: your problem sounds unrelated to this issue. Some platform-specific race condition, perhaps, or problem with modified but unsaved files.
(In reply to comment #9) > Created attachment 119262 [details] > Project to use for reproduction. BTW this ZIP is huge. In the future be sure to run a clean build on a project before zipping it up for an attachment, and delete nbproject/private/ as well. Or simply use the new Export Project > To ZIP feature in NB 7.2 which automatically skips over nonsharable files incl. build products.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss