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
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
(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
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
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
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
(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