openldap-bugs

openldap-bugs@openldap.org

1 participants
21063 discussions

Re: (ITS#8072) ERROR- ldap-export unsuccessfully
by hyc＠symas.com 05 Mar '15

05 Mar '15

moinuddin_khan.h(a)alcatel-lucent.com wrote: > Full_Name: Moinuddin Khan > Version: 2.4.38 > OS: RHEL 6.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (135.245.115.244) > > > Hi, > > Ldap backup was working fine but all of sudden backup were unsuccessful. > > Not sure the reason because no changes been done on LDAP and also on machine. > > Following below error is seen while doing the backup > ----- > ------------------------------------------------------------------------------- > DATE: 02/21/15 TIME: 17:07:01: Archiving files > tar: Removing leading `/' from member names > 54e8ad25 mdb_db_open: database "cn=accesslog" cannot be opened, err -30790. Error -30790 is MDB_READERS_FULL - the configured number of concurrent readers has been reached. You need to raise this limit in your configuration, read the slapd-mdb(5) manpage. Also consider upgrading to a current release, which includes the error's message text as well as the error code. Note: the ITS is for actual bug reports - there is nothing in this report that indicates any bug in OpenLDAP software. You should have sent this question to the -technical mailing list. Closing this ITS. > Restore from backup! > 54e8ad25 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open > failed! (-30790) > slap_startup failed > ------------------------------------------------------------------------------- > DATE: 02/21/15 TIME: 17:07:01: ERROR- ldap-export unsuccessfully ! > DATE: 02/21/15 TIME: 17:07:01: Check /opt/openldap/log/backup_restore.log ! > ------- > > We are using > > # The backup/restore mechanism for openldap/server is based on: > # 1. slapcat > # 2. config files archive If you're using cn=config you should just use slapcat for everything. > > Regards > Moinuddin > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8072) ERROR- ldap-export unsuccessfully
by moinuddin_khan.h＠alcatel-lucent.com 05 Mar '15

05 Mar '15

Full_Name: Moinuddin Khan Version: 2.4.38 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.115.244) Hi, Ldap backup was working fine but all of sudden backup were unsuccessful. Not sure the reason because no changes been done on LDAP and also on machine. Following below error is seen while doing the backup ----- ------------------------------------------------------------------------------- DATE: 02/21/15 TIME: 17:07:01: Archiving files tar: Removing leading `/' from member names 54e8ad25 mdb_db_open: database "cn=accesslog" cannot be opened, err -30790. Restore from backup! 54e8ad25 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open failed! (-30790) slap_startup failed ------------------------------------------------------------------------------- DATE: 02/21/15 TIME: 17:07:01: ERROR- ldap-export unsuccessfully ! DATE: 02/21/15 TIME: 17:07:01: Check /opt/openldap/log/backup_restore.log ! ------- We are using # The backup/restore mechanism for openldap/server is based on: # 1. slapcat # 2. config files archive Regards Moinuddin

1 0

Re: (ITS#8070) test023 failures
by hyc＠symas.com 04 Mar '15

04 Mar '15

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms080008030100090401070303 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > quanah(a)zimbra.com wrote: >> Confirmed with Howard this is a timing dependent script, and it's affec= > ted=20 >> by recent changes to the code base. refint used to do all its work=20 >> inline, but now it uses a separate thread, so on a slow enough machine,= > it=20 >> may not be done by the time the script runs its ldapsearch. > > Hmm, I'm not convinced that it really makes sense to have slapo-refint do= > ing > its job asynchronously. I'm very much concerned about data consistency w= > ith > sync jobs relying on e.g. group membership being immediately updated etc.= > > > I'd rather prefer to have slow write operations than having inconsistent > references. Can this be made configurable? Please...! > > Also how about impact on transaction handling in upcoming 2.5.x? Good questions for 2.5. accesslog reentrancy used to be a problem, back in 2006 but other changes have been made since then to remove that obstacle. Using LDAP txns internally would also fix the backendDB reentrancy issues. What sync jobs are you referring to? LDAP replication only promises eventual consistency; relying on instantaneous/continuous consistency here means you've got a design flaw. > Ciao, Michael. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8070) test023 failures
by hyc＠symas.com 04 Mar '15

04 Mar '15

richton(a)nbcs.rutgers.edu wrote: > On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote: > >>> Seeing occasional failures on test023 using mdb. Takes a few runs (~30 >>> for me, recently) but seems to be more than a one-off... >>> >> >> Confirmed with Howard this is a timing dependent script, and it's >> affected by recent changes to the code base. refint used to do all its >> work inline, but now it uses a separate thread, so on a slow enough >> machine, it may not be done by the time the script runs its ldapsearch. >> >> I.e., doesn't appear to be a code bug. The test needs tweaking at some >> point to add some sleeps to handle this. :P > > Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference > from your earlier email)? That one failed after 80 runs. The refint behavior (using a separate thread) is not a recent change - that was made in 2006. But the test script is even older. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8070) test023 failures
by michael＠stroeder.com 04 Mar '15

04 Mar '15

This is a cryptographically signed message in MIME format. --------------ms080008030100090401070303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > Confirmed with Howard this is a timing dependent script, and it's affec= ted=20 > by recent changes to the code base. refint used to do all its work=20 > inline, but now it uses a separate thread, so on a slow enough machine,= it=20 > may not be done by the time the script runs its ldapsearch. Hmm, I'm not convinced that it really makes sense to have slapo-refint do= ing its job asynchronously. I'm very much concerned about data consistency w= ith sync jobs relying on e.g. group membership being immediately updated etc.= I'd rather prefer to have slow write operations than having inconsistent references. Can this be made configurable? Please...! Also how about impact on transaction handling in upcoming 2.5.x? Ciao, Michael. --------------ms080008030100090401070303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTAzMDQwOTI0MDNaMCMGCSqGSIb3DQEJBDEWBBSHnyxsul9L wIajeXJzOyHvpTlhrTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEASmg+fUZV O5b1dwe+th1NR18cxrOdeA4DYxQZ4EaGtSnYM/arTV4j1TrREnClciZa7LHdpC6AoihZG82D bxg6IKDShd/N3gZI8i7ghR+tTh4mE6Su8dyaJwekGRSnMg57mzEfq/tZ35uZlfoi8GwvkYwH P8R2LGYp1ffU65aURmq1qp949McoFae9QqMU5+mJsP2vDoNcIAA2+xSbehAIRQpLjN6qzlHM Oq+34mAhE95YtsTrkYW954zonBRooHHTNJLj4R62dSVelsfHindMu7byStYacL4eF8Xmrrb7 txsHofGRZrlJeztVHU26UwBMWCSM825dkEK79LAW1G8oBQAAAAAAAA== --------------ms080008030100090401070303--

1 0

Re: (ITS#8070) test023 failures
by richton＠nbcs.rutgers.edu 04 Mar '15

04 Mar '15

On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote: >> Seeing occasional failures on test023 using mdb. Takes a few runs (~30 >> for me, recently) but seems to be more than a one-off... >> > > Confirmed with Howard this is a timing dependent script, and it's > affected by recent changes to the code base. refint used to do all its > work inline, but now it uses a separate thread, so on a slow enough > machine, it may not be done by the time the script runs its ldapsearch. > > I.e., doesn't appear to be a code bug. The test needs tweaking at some > point to add some sleeps to handle this. :P Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference from your earlier email)? That one failed after 80 runs.

1 0

Re: (ITS#8070) test023 failures
by quanah＠zimbra.com 03 Mar '15

03 Mar '15

--On Monday, March 02, 2015 10:17 PM +0000 richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739 > OS: Linux > URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > Seeing occasional failures on test023 using mdb. Takes a few runs (~30 > for me, recently) but seems to be more than a one-off... > Confirmed with Howard this is a timing dependent script, and it's affected by recent changes to the code base. refint used to do all its work inline, but now it uses a separate thread, so on a slow enough machine, it may not be done by the time the script runs its ldapsearch. I.e., doesn't appear to be a code bug. The test needs tweaking at some point to add some sleeps to handle this. :P --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8070) test023 failures
by quanah＠zimbra.com 03 Mar '15

03 Mar '15

--On Monday, March 02, 2015 10:17 PM +0000 richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739 > OS: Linux > URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > Seeing occasional failures on test023 using mdb. Takes a few runs (~30 > for me, recently) but seems to be more than a one-off... Doesn't happen for me with 4129e246a85a6d1f0033466ed2c7fb51c6dee508 (Feb 6th), so it is something recently introduced. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8070) test023 failures
by richton＠nbcs.rutgers.edu 02 Mar '15

02 Mar '15

Full_Name: Aaron Richton Version: OPENLDAP_REL_ENG_2_4_40-178-gba9a739 OS: Linux URL: https://www.nbcs.rutgers.edu/~richton/testrun-test023-fail.tar.bz2 Submission from: (NULL) (128.6.31.135) Seeing occasional failures on test023 using mdb. Takes a few runs (~30 for me, recently) but seems to be more than a one-off...

1 0

(ITS#8069) MDb library patch: Use explicit Windows API functions for char* strings
by pmedvedev＠gmail.com 28 Feb '15

28 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) Most Windows API functions such as CreateFile(), CreateMutex(), OpenMutex() that accept string arguments, are defined with suffix W or A for appropriate wchar_t* or char* strings, depending of _UNICODE preprocessor define. Calling explicit functions with A suffix would eliminate compile errors when _UNICODE is defined. As a further enhancement, I think path argument encoding should be documented (probably UTF-8?) for such functions as mdb_env_open(), mdb_env_copy(), mdb_env_copy2(), and mdb_env_get_path(). This prevent possible problems with non-latin characters in path names on Windows. In this case, LMDB implementation on Windows should perform path conversion to UTF-16 and explicit call to CreateFileW() in mdb_env_open() and mdb_env_copy2() functions. --- libraries/liblmdb/mdb.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index a54ce83..a669da6 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -1409,7 +1409,7 @@ mdb_strerror(int err) ; } buf[0] = 0; - FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | + FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, err, 0, ptr, sizeof(buf), (va_list *)pad); return ptr; @@ -4413,7 +4413,7 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) off_t size, rsize; #ifdef _WIN32 - env->me_lfd = CreateFile(lpath, GENERIC_READ|GENERIC_WRITE, 909env->me_lfd = CreateFileA(lpath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); #else @@ -4517,9 +4517,9 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int xcxcl) mdb_hash_enc(&val, encbuf); sprintf(env->me_txns->mti_rmname, "Global\\MDBr%s", encbuf); sprintf(env->me_txns->mti_wmname, "Global\\MDBw%s", encbuf); - env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); + env->me_rmutex = CreateMutexA(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); if (!env->me_rmutex) goto fail_errno; - env->me_wmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_wmname); + env->me_wmutex = CreateMutexA(&mdb_all_sa, FALSE, env->me_txns->mti_wmname); if (!env->me_wmutex) goto fail_errno; #elif defined(MDB_USE_SYSV_SEM) unsigned short vals[2] = {1, 1}; @@ -4569,9 +4569,9 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) goto fail; %%D #ifdef _WIN32 - env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); + env->me_rmutex = OpenMutexA(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); if (!env->me_rmutex) goto fail_errno; - env->me_wmutex =pepenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_wmname); + env->me_wmutex = OpenMutexA(SYNCHRONIZE, FALSE, env->me_txns->mti_wmname); if (!env->me_wmutex) goto fail_errno; #elif defined(MDB_USE_SYSV_SEM) semid = env->me_txns->mti_semid; @@ -4686,7 +4686,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode len = OPEN_ALWAYS; } mode = FILE_ATTRIBUTE_NORMAL; - env->me_fd = CreateFile(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, + env->me_fd = CreateFileA(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, len, mode, NULL); #else if (F_ISSET(flags, MDB_RDONLY)) @@ -4716,7 +4716,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode */ #ifdef _WIN32 len = OPEN_EXISTING; - % e9env->me_mfd = CreateFile(dpath, oflags, + env->me_mfd = CreateFileA(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, len, mode | FILE_FLAG_WRITE_THROUGH, NULL); #else @@ -8981,7 +8981,7 @@ mdb_env_copy2(MDB_env *env, const char *path, unsigned int flags) * already in the OS cache. */ #ifdef _WIN32 - newfd = CreateFile(lpath, GENERIC_WRITE, 0, NULL, CREATE_NEW, + newfd = CreateFileA(lpath, GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_FLAG_NO_BUFFERING|FILE_FLAG_WRITE_THROUGH, NULL); #else newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); -- 1.9.5.msysgit.0

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs