This is typical on Windows, if the file hasn’t been closed and released by a process… Could be a sign of a bug, or not !
My 2 cents. Ludo — Ludovic Poitou http://ludopoitou.com On 16 August 2018 at 06:50:20, Emmanuel Lécharny (elecha...@gmail.com) wrote: Hi Lucas, Yes, Windows is having hard time deleting transient files. This is visible on jenkins. Not sure we can do anythig regarding this problem, to me it seems that there is some kind of temporary lock put of those files, and the deletion just fails... Le 16/08/2018 à 06:30, Lucas Theisen a écrit : > +1 > > However, test fail on Windows during attempts to delete test files. Not > sure if that is much of a concern... > > [ERROR] Errors: > [ERROR] JdbmIndexTest.cleanup:127 ▒ IO ERR_17010_UNABLE_DELETE_FILE > Unable to delete f... > [ERROR] JdbmRdnIndexTest.cleanup:128 ▒ IO ERR_17010_UNABLE_DELETE_FILE > Unable to delet... > [INFO] > [ERROR] Tests run: 124, Failures: 0, Errors: 2, Skipped: 0 > > > > On Aug 15, 2018 4:44 PM, "Emmanuel Lécharny" <elecha...@gmail.com> wrote: > > > > Le 15/08/2018 à 21:01, Stefan Seelmann a écrit : >> +1 >> >> * Verified checksums and signatures >> * Built source on Linux with OpenJDK 8 and 11-ea25 >> * Run installer tests: >> * bin, tar.gz and deb on Debian 9 With OpenJDK 8 and 11-ea24 >> * rpm on Fedora 21 (very old!) with Java 8 >> >> Note: when starting the server there is output like this: >> [18:19:00] ERROR [org.apache.directory.api.ldap.model.entry.Value] - >> ERR_13725_CANNOT_HANDLE_NAME_AND_OPTIONAL_UID_NORM I do not know how to >> handle NameAndOptionalUID normalization with obje... > > Yes, this should be a warning. > > What happens is that the server will load all the schemas, recursively, > and for each schema, the AT, OC, etc.... Some of them are loaded before > the parts they depend on. Each of the attributeTypes and Object classes > are checked against the registries, and if they don't exist, such an > error is produced. Then a workaround is applied: > > ... > entry.addAttribute( attributeType, attributeValue ); // > Here, we will get an exception > } > catch ( Exception e ) > { > // The attribute does not exist already, create a fake one > if ( ( schemaManager != null ) && schemaManager.isRelaxed() ) > // Here, we create a fake object waiting for the real one to be loaded > > Later on, when all the schemas has finally been loaded, all those > temporary objects are discarded, and a global check is done, which means > if there is some missing AT, OC or anything else, and error will be > produced. > > Typically, here, an attributeType's super attribute is not yet loaded in > the registry (apacheDnsDomainName): > > version: 1 > dn: > m-oid=1.3.6.1.4.1.18060.0.4.2.2.6,ou=attributeTypes,cn=apachedns,ou=schema > m-singlevalue: TRUE > m-obsolete: FALSE > m-description: The domain name of the name server that was the primary > source of data for this zone > m-usage: USER_APPLICATIONS > creatorsname: uid=admin,ou=system > m-collective: FALSE > m-oid: 1.3.6.1.4.1.18060.0.4.2.2.6 > m-supattributetype: apacheDnsDomainName > m-nousermodification: FALSE > m-syntax: 1.3.6.1.4.1.1466.115.121.1.26 > objectclass: metaAttributeType > objectclass: metaTop > objectclass: top > m-name: apacheDnsSoaMName > m-equality: caseIgnoreIA5Match > > because attribute files are loaded in an order that is not the one we > can guaranty. That would be another story if the schema elements were > not in a distinct file for each one of them. > > I agree there is room for improvement here, typically not storing each > AT, OC, etc in a separated file, but as a whole in a .schema file, as > it's done in OpenLDAP. OTOH, that would make the schema update way more > complex, as we would have to modify the schema file and create a new one > for each modification, while the way we work allows us to simply update > one single fle when we modify the schema. > > It's a implementation choice. > > Ideally speaking, we should mute the logs in this case, or make it a > warning, not a error. > > > -- Emmanuel Lecharny Symas.com directory.apache.org
