[bugfix] port of rev11673 Thomas White reported both in Sourceforge bug tracker (2981937) and eXist-devel list a couple of bugs related to collections containing both binary resources and subcollections on deletion and movement. These bugs lead to an out of sync database, where the binary resource listed internally and the files that actually are stored in the file system at the location they are expected differ. So, errors like unreachable binary resources are fired:
[bugfix] port of rev11673
Thomas White reported both in Sourceforge bug tracker (2981937) and
eXist-devel list a couple of bugs related to collections containing
both binary resources and subcollections on deletion and movement. These
bugs lead to an out of sync database, where the binary resource listed
internally and the files that actually are stored in the file system at
the location they are expected differ. So, errors like unreachable binary
resources are fired:

514140 [qtp11513418-62] WARN org.eclipse.jetty.util.log - Nested in javax.servlet.ServletException: An error occurred: d:\eXist2\webapp\WEB-INF\data\fs\db\exe\res\exe-res\js\jquery.taconite.js (The system cannot find the path specified):
java.io.FileNotFoundException: d:\eXist2\webapp\WEB-INF\data\fs\db\exe\res\exe-res\js\jquery.taconite.js (The system cannot find the path specified)

Even worse, the fact that files stay in the file system after collections
deletions is a security issue as well.

Both bugs come from the limitations of File.renameTo method. If you try
moving a directory or a file to a destination directory where there is
already a file or a directory with the same name, the operation is not made.

When a collection A with binary resources and subcollections B,C,D,...
with also binary resources, is going to be removed, the recursive
implementation of NativeBroker.removeCollection calls first
NativeBroker.removeCollection on B,C,D,..., and then it renames the
collection A, so it is placed on the binary log dir of the current
transaction. As the binary log contents are only disposed once the
transaction has properly finished, the File.renameTo operation on A
does not work properly, because there is already a directory with
that name in the binary log dir, leaving those contents in its origin.

Something similar happens when NativeBroker.moveCollection is called and
there is already either a binary resource or a collection containing a
binary resource with that name. The reason: the movement operation at
binary resources level is done using File.renameTo call. In this scenario
the operation fails, but binary resources in that moved collection are
registered as so, leading to java.io.FileNotFoundException in further
accesses.

So, this patch fixes both bugs. The first one is fixed moving the code
which handle binary resource collection removal just before the recursive
calls on subcollections. The second one is fixed checking whether a
destination collection exists at filesystem level just before the movement,
so previous contents are moved to the binary log dir and registered using
a RenameBinaryLoggable object.

git-svn-id: 1623499149f5af833cfad2814dce82e821210f6f@11685 8784284e-840f-0410-bd5a-a6a6012a0d1a

kingargyle/exist-1.4.x,orbeon/eXist-1.4.x,orbeon/eXist-1.4.x,orbeon/eXist-1.4.x,kingargyle/exist-1.4.x,kingargyle/exist-1.4.x,kingargyle/exist-1.4.x,orbeon/eXist-1.4.x,orbeon/eXist-1.4.x,kingargyle/exist-1.4.x,orbeon/eXist-1.4.x,kingargyle/exist-1.4.x