Full_Name: Sergey Brester Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.154.98.131) If I save many data into LMDB file placed in network share, only the latest key is really in the database after reopen. Tested single threaded (1 process, 1 thread). No matter which flags supplied to mdb_env_open... So repeateable writing of 10 keys (total 960 times) should result in: Target-state: 10 keys { "some-key-0": "951", "some-key-1": "952", "some-key-2": "953", "some-key-3": "954", "some-key-4": "955", "some-key-5": "956", "some-key-6": "957", "some-key-7": "958", "some-key-8": "959", "some-key-9": "960" } After reopen of database you'll see: Actual-state: 1 key { "some-key-9": "960" } Doing the same on local drive works fine and actual state is equal target state.
serg.brester@sebres.de wrote: > Full_Name: Sergey Brester > Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.154.98.131) > > > If I save many data into LMDB file placed in network share, only the latest key > is really in the database after reopen. The docs explicitly state not to use LMDB with remote filesystems. http://www.lmdb.tech/doc/ Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/