I'm getting a failure on the second commit of XML data via the basexclient command (from my git hook code).
I've created a gist here: https://gist.github.com/dc9f6d55d891b06ecae9.git with relevant logs and the data/ directory. The exception reported is: ================== Contrext01:dfst-sample-project ekimber$ git add .;git commit -m "updated test file" Running: basexclient -c CHECK\ dfst_master\;\ OPEN\ dfst_master\;\ REPLACE\ docs/topic-01.dita\ /Users/ekimber/workspace-dfst/dfst-sample-project/docs/topic-01.dita -U admin -P admin -p 1984 -n localhost Running: basexclient -c CHECK\ dfst_master\;\ OPEN\ dfst_master\;\ REPLACE\ dfst/metadata.xml\ \<dfst_metadata\>\<gitstate\>\<branch\>master\</branch\>\<commit\>8d264e1e7 3d5596758a069a4355920c448a5b41d\</commit\>\</gitstate\>\</dfst_metadata\> -U admin -P admin -p 1984 -n localhost Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 8.0.3 Java: Oracle Corporation, 1.7.0_65 OS: Mac OS X, x86_64 Stack Trace: java.lang.RuntimeException: Data Access out of bounds: - pre value: 21 - #used blocks: 1 - #total locks: 1 - access: 0 (1 > 0] at org.basex.util.Util.notExpected(Util.java:60) at org.basex.io.random.TableDiskAccess.cursor(TableDiskAccess.java:462) at org.basex.io.random.TableDiskAccess.read1(TableDiskAccess.java:148) at org.basex.data.Data.kind(Data.java:304) at org.basex.data.atomic.Replace.getInstance(Replace.java:42) at org.basex.data.atomic.AtomicUpdateCache.addReplace(AtomicUpdateCache.java:9 5) at org.basex.core.cmd.Replace.replace(Replace.java:95) at org.basex.core.cmd.Replace.run(Replace.java:57) at org.basex.core.Command.run(Command.java:379) at org.basex.core.Command.execute(Command.java:95) at org.basex.server.ClientListener.run(ClientListener.java:146) [master 8d264e1] updated test file 1 file changed, 1 insertion(+), 1 deletion(-) Contrext01:dfst-sample-project ekimber$ ================= The first update succeeds, the second one fails. The second one is committing literal XML on the command while the first is committing a file on the file system. This behavior is consistent: if I drop the database, restart the server, the repeat this test, I get the same failure. Is this my user error or a bug? Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
