October 2008 - openldap-bugs

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)

by hyc＠symas.com

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> I guess we should be using #ifdef _WIN32 / ReplaceFile instead of >> rename() in this case. > > Argh, why didn't that arrive before I wrote my reply? I don't know > Windows... > I don't think it's worth the effort to learn, really. But all of the Windows API documentation is on msdn.microsoft.com if you're inclined to read it. MoveFileEx(old,new,MOVEFILE_REPLACE_EXISTING) would also be fine. http://msdn.microsoft.com/en-us/library/aa365240(VS.85).aspx -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 1 month

1
0
0 / 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)

by h.b.furuseth＠usit.uio.no

hyc(a)symas.com writes: > I guess we should be using #ifdef _WIN32 / ReplaceFile instead of > rename() in this case. Argh, why didn't that arrive before I wrote my reply? I don't know Windows... -- Hallvard

15 years, 1 month

1
0
0 / 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)

by h.b.furuseth＠usit.uio.no

emmanuel.duru(a)atosorigin.com writes: > Reading back-ldif code I see that when modifying an entry, back-ldif > creates a temporary file containing the modified entry, and then > renames the temporary file to the entry file. > > On Windows, renaming a file to an already existing file does not work, > it gets an ERROR_ALREADY_EXISTS error (183), error code which is > ignored by back-ldif. If so we should rename cn=foo.ldif to cn=foo.save before moving the new file in place and delete the .save afterwards, so the old file won't be lost if slapd or the machine dies as just the wrong time. Might try the same as a fallback on Mac/Unix if rename(tmpfile, ldiffile) fails there. There are lots of strange OSes out there, or for that matter an OS might mount a filesystem from another OS. It still needs manual cleanup though. But we could maintain a "state" file in the database directory which says which entry was last written, and on startup in write mode rename that file back. Read mode slapcat could read any .save files as well as .ldif files. Or all acceses to .ldif files could, though that doubles the number of failed open/stat() calls. -- Hallvard

15 years, 1 month

1
0
0 / 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)

by hyc＠symas.com

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > On Windows, modifications are not saved on file by back-ldif. > This is the case for example with cn=config. > > Reading back-ldif code I see that when modifying an entry, back-ldif creates a > temporary file containing the modified entry, and then renames the temporary > file to the entry file. > On Windows, renaming a file to an already existing file does not work, it gets > an ERROR_ALREADY_EXISTS error (183), error code which is ignored by back-ldif. > > > I guess we should be using #ifdef _WIN32 / ReplaceFile instead of rename() in this case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 1 month

1
0
0 / 0

(ITS#5774) Modifications not saved on file by back-ldif (on Windows)

by emmanuel.duru＠atosorigin.com

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) On Windows, modifications are not saved on file by back-ldif. This is the case for example with cn=config. Reading back-ldif code I see that when modifying an entry, back-ldif creates a temporary file containing the modified entry, and then renames the temporary file to the entry file. On Windows, renaming a file to an already existing file does not work, it gets an ERROR_ALREADY_EXISTS error (183), error code which is ignored by back-ldif.

15 years, 1 month

1
0
0 / 0

RE: (ITS#5769) Behaviour of ldap_sort_entries on a multivalued attribute

by emmanuel.duru＠atosorigin.com

OK, forget it. > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : jeudi 23 octobre 2008 16:13 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5769) Behaviour of ldap_sort_entries on a multivalued > attribute > > emmanuel.duru(a)atosorigin.com wrote: > > > Currently, ldap_sort_entries when used with a multivalued attribute > assumes that > > the attribute values are in the same order for all the entries. It would > be > > better if this was not the case. > > For example, I would like to use ldap_sort_entries to sort entries > according to > > objectclass attribute, so as to group entries by kind of objects. > > Let be 3 entries: > > ==>cn=n1, objectclass: person, organizationalperson > > ==>ou=ou1, objectclass: organizationalunit > > ==>cn=n2, objectclass: organizationalperson, person > > result of ldap_sort_entries on objectclass: n2, ou1, n1, whereas I > expected n1, > > n2, ou1. > > ldap_sort_entries() is deprecated. As a consequence, I would not expect > any activity on it. It is the client's duty to sort the way it likes. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

15 years, 1 month

1
0
0 / 0

Re: (ITS#5773) bi_entry_get_rw() and overlays issue

by ando＠sys-net.it

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I think bi_entry_get_rw() needs work. > > Or maybe phase it out in favor of some other call? > >> In fact, as also discussed in ITS#5628, callers either return the >> entry or have no means to modify the arguments of the request. > > It has more troubles than that. See e.g. the notes about passing rw=1 > (write) to it here: > http://www.openldap.org/lists/openldap-devel/200803/msg00055.html > And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which > says to pass an rw=1 argument to bi_entry_release_rw(). Well, I see many places where an entry needs to be fetched. Typically, it needs to be done read-only. So the difference between bi_entry_get_ro() and an internal search is that if we are fine with the entry in-cache, we save lots of manipulation. However this might no longer suffice when overlays muck with the entry (like slapo-rwm). Moreover, when overlays are present, I see the need to: 1) run it like it came from outside, going thru all the overlays 2) go straight to the underlying database 3) go thru overlays starting at some point (e.g. when called from inside an overlay under the assumption the entry is fetched as that overlay would see it, so with only any possible mucking from overlays layered deeper than the caller). This probably needs to modify the way callbacks are actually called, allowing some "after self" feature in playing not just the overlay list, but also the response (and the cleanup). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

15 years, 1 month

1
0
0 / 0

Re: (ITS#5773) bi_entry_get_rw() and overlays issue

by h.b.furuseth＠usit.uio.no

ando(a)sys-net.it writes: > I think bi_entry_get_rw() needs work. Or maybe phase it out in favor of some other call? > In fact, as also discussed in ITS#5628, callers either return the > entry or have no means to modify the arguments of the request. It has more troubles than that. See e.g. the notes about passing rw=1 (write) to it here: http://www.openldap.org/lists/openldap-devel/200803/msg00055.html And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which says to pass an rw=1 argument to bi_entry_release_rw(). -- Hallvard

15 years, 1 month

1
0
0 / 0

(ITS#5773) bi_entry_get_rw() and overlays issue

by ando＠sys-net.it

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I think bi_entry_get_rw() needs work. In fact, as also discussed in ITS#5628, callers either return the entry or have no means to modify the arguments of the request. This can be critical, for example, when slapo-rwm(5) is involved. In many cases, it might need to rewrite the ndn, or to map the attribute and the objectClass. However, this cannot be done without returning the entry, and thus directly performing a bi_entry_get_rw() to the original database, bypassing any further stacked overlay. Probably, the API of this call, and that of bi_entry_release_rw() should be modified in conformity to that of BI_op_func, possibly adding further structs to the main union. I'm not going to implement this right now, as I fear I might have overlooked something. Moreover, this change would have significant impact on existing code, since these calls are widely used. In the meanwhile I'm adding support for these two calls to slapo-rwm(5) along the above lines. p.

15 years, 1 month

1
0
0 / 0

(ITS#5772) slapo-rwm does not normalize rewritten DN-valued attributes

by ando＠sys-net.it

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Only a_vals are rewritten; this is not an issue when used with back-ldap, but can be an issue when used with back-relay and in all cases overlays are expected to interact. A fix is coming. p.

15 years, 1 month

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2008