Re: [Exist-development] Binary resources not deleted when a collection is moved into existing collection with the same name.

[José M. F. G. <jm...@us...>]

Hi Thomas,
	well, (lack of) recursive deletion of binary contents it is a different bug. AFAIHS it is related to the recursive implementation of NativeBroker.removeCollection, RenameBinaryLoggable and usage of File.renameTo. In current implementation, when a collection is erased, "binary" child subcollections are erased before parent ones. But as it is not a real erase, but a directory movement to a subdirectory inside fs.journal, when File.renameTo is called in parent collection for binary contents, it fails because the destination path already exists.

	Attached patch contains both the previous fix for move collection bug, and new fix for remove collection bug. Could you test it, please? If it works for you I'm sending the changes to eXist trunk.

	Best Regards,
		José María

On 04/09/10 10:12, Thomas White wrote:
> José,
> Thank you very much for helping me with this important issue.
> Unfortunately I when a collection with binary resources is deleted the
> files in the file system under webapp\WEB-INF\data\fs\db still remain.
> If you run the example file you can replicate the problem on your box.
> I am sending you the zip file with the test case (it is the same as the
> file I uploaded when I submitted the bug).
> This example only imports binary files. I think we need to fix this
> first. Then we can continue with the collection move.
> Regards,
> Thomas
>
>
> ------
>
> Thomas White
>
> Mobile:+44 7711 922 966
> Skype: thomaswhite
> gTalk: thomas.0007
> Linked-In:http://www.linkedin.com/in/thomaswhite0007
> facebook: http://www.facebook.com/thomas.0007
>
>
>
> 2010/4/8 José María Fernández González <jm...@us...
> <mailto:jm...@us...>>
>
>     Hi Thomas,
>             I have taken a look at the bug you have reported, and
>     following the codepaths the reason is that in NativeBroker, in
>     moveBinaryFork, there is no check about the (lack of existence of)
>     destination at binary resources level, so the move operation fails
>     when there is already a binary resource with the same path. I have
>     created a fix (see attached source patch), and I would like you to
>     test it before I commit the changes to eXist trunk.
>
>             Best Regards,
>                     José María
>
>
>     On 03/31/10 15:45, Thomas White wrote:
>
>         I was wandering if anybody can have a look at this issue.
>         It is pretty serious to me because after a second file import
>         eXist goes
>         out of sync between the binary resource listed internally and
>         the files
>         that actually are stored in the file system at the location they are
>         expected. And second, the fact that files stay in the file system
>         after collections deletions is a security issue as well.
>         I really hope somebody will be able to go to the bottom of this
>         problem.
>         Thomas
>
>         ------
>
>         Thomas White
>
>         Mobile:+44 7711 922 966
>         Skype: thomaswhite
>         gTalk: thomas.0007
>         Linked-In:http://www.linkedin.com/in/thomaswhite0007
>         facebook: http://www.facebook.com/thomas.0007
>
>
>
>         On 25 March 2010 17:28, Thomas White <tho...@gm...
>         <mailto:tho...@gm...>
>         <mailto:tho...@gm... <mailto:tho...@gm...>>>
>         wrote:
>
>             EXIST_HOME  is  D:\eXist2
>             JAVA SDK HOME C:\Java\jdk1.6.0_16
>             Has anyone been able to reproduce this bug?
>             Thomas
>
>
>
>
>         ------------------------------------------------------------------------------
>         Download Intel&#174; Parallel Studio Eval
>         Try the new software tools for yourself. Speed compiling, find bugs
>         proactively, and fine-tune applications for parallel performance.
>         See why Intel Parallel Studio got high marks during beta.
>         http://p.sf.net/sfu/intel-sw-dev
>
>
>
>         _______________________________________________
>         Exist-development mailing list
>         Exi...@li...
>         <mailto:Exi...@li...>
>         https://lists.sourceforge.net/lists/listinfo/exist-development
>
>
>     --
>     "La violencia es el último recurso del incompetente"
>             - Salvor Hardin en "La Fundación" de Isaac Asimov
>     "Premature optimization is the root of all evil." - Donald Knuth
>
>     José María Fernández González
>     e-mail: jos...@gm... <mailto:jos...@gm...>
>
>

-- 
"La violencia es el último recurso del incompetente"
	- Salvor Hardin en "La Fundación" de Isaac Asimov
"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
e-mail: jos...@gm...