On Fri, Aug 26, 2011 at 1:06 PM, Wendy Smoak <[email protected]> wrote: > On Fri, Aug 26, 2011 at 1:47 PM, Dan Armbrust > <[email protected]> wrote: > >> Anyway, feature requests are beside the point. Normally the delete >> works for me. However, this time, while it reported that the delete >> was successful, it in fact was not, according to the browser - as the >> item still appeared. > > What url? If it was a /browse/ url, it's possible the database hadn't > been updated it would show without actually being there.
It was still appearing in the browse area... although I'm 99% sure I looked at the webdav url as well, and I thought it was there too. But I'm not positive on that. It appears that it has partially cleaned itself up over the weekend - it no longer appears in the browse GUI. Though, I did notice that the path to the file still exists in the webdav view, and there are still metadata files there. But the file itself is gone. But I suspect that is just a known implementation issue... that if you create a path like a/b/c/, and then delete everything under c, it doesn't actually ever delete c. But the browse view at least doesn't show c any longer, as it doesn't contain anything. So that is good. > > Did you happen to check the file system to know for sure whether it > was actually gone? > I didn't check at the time. But it is gone now. >> So, I tried to delete it again, which ended badly: >> Problem accessing /archiva/deleteArtifact!doDelete.action. Reason: >> INTERNAL_SERVER_ERROR >> Caused by: >> >> java.lang.NullPointerException > > In any case, it shouldn't do that. Are you able to reproduce it? Yea, it would happen over and over again at the time. But it appears that a maintenance task has cleaned it up since then. The version is 1.3.4. Someday, maybe I'll get back to current :)
