Bug 345541 - db2ldif -u or -s returns different number of processed entries.
db2ldif -u or -s returns different number of processed entries.
Status: CLOSED INSUFFICIENT_DATA
Product: 389
Classification: Community
Component: Command Line Utilities (Show other bugs)
1.0.4
All Linux
medium Severity low
: ---
: ---
Assigned To: Noriko Hosoi
Chandrasekar Kannan
:
Depends On:
Blocks: 249650
  Show dependency treegraph
 
Reported: 2007-10-22 13:05 EDT by Thomas Blanchin
Modified: 2015-01-04 18:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-19 19:13:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Blanchin 2007-10-22 13:05:31 EDT
Description of problem:
"db2ldif" -s <suffix> or -u <backend> options returns different message, while
output files are identical.

[root@dir32b01 slapd-dir32b01]# ./db2ldif -s dc=ldap -a /tmp/suffix.ldif
[22/Oct/2007:18:47:24 +0200] - Backend Instance: userRoot
ldiffile: /tmp/suffix.ldif
[22/Oct/2007:18:47:24 +0200] - export userRoot: Processed 201 entries (100%).
[root@dir32b01 slapd-dir32b01]# ./db2ldif -n userRoot -a /tmp/backend.ldif
ldiffile: /tmp/backend.ldif
[22/Oct/2007:18:47:27 +0200] - export userRoot: Processed 671 entries (100%).

# No difference between both output files.
[root@dir32b01 slapd-dir32b01]# diff /tmp/suffix.ldif /tmp/backend.ldif 
[root@dir32b01 slapd-dir32b01]# echo $?
0
[root@dir32b01 slapd-dir32b01]# 


Version-Release number of selected component (if applicable):


How reproducible:
I tried it on my multi replicated servers (4), and single replicated (1), and I
got the same results.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Number of processed entries shown to be differents

Expected results:
Number of processed entries shown to be the same

Additional info:
It's only a display problem. The number of processed entries are actually the same.
Comment 3 Noriko Hosoi 2008-12-01 20:29:44 EST
I'm trying to reproduce the problem.

I created a test ldif with a utility dbgen.pl and imported it to the server.
# dbgen.pl -o example1k.ldif -n 1000

Next, ran db2ldif with -s and -n, but the reported export entry numbers were the same:
# ./db2ldif -s "dc=example,dc=com" -a /tmp/example.ldif
Exported ldif file: /tmp/example.ldif
[01/Dec/2008:17:08:38 -0800] - Backend Instance: userRoot
ldiffile: /tmp/example.ldif
[01/Dec/2008:17:08:39 -0800] - export userRoot: Processed 1000 entries (99%).
[01/Dec/2008:17:08:39 -0800] - export userRoot: Processed 1006 entries (100%).
[01/Dec/2008:17:08:39 -0800] - All database threads now stopped

# ./db2ldif -n userRoot -a /tmp/example2.ldif
Exported ldif file: /tmp/example2.ldif
ldiffile: /tmp/example2.ldif
[01/Dec/2008:17:09:42 -0800] - export userRoot: Processed 1000 entries (99%).
[01/Dec/2008:17:09:42 -0800] - export userRoot: Processed 1006 entries (100%).
[01/Dec/2008:17:09:42 -0800] - All database threads now stopped

# diff /tmp/example.ldif /tmp/example2.ldif 
# echo $?
0

Could there be any special condition to duplicate the bug?
Comment 4 Noriko Hosoi 2009-01-15 18:41:17 EST
Can we have a test data to reproduce the problem?

If we cannot reproduce this bug, we need to close it for now.

Thanks.
Comment 5 Chandrasekar Kannan 2009-01-19 19:13:07 EST
per bug council, closing w/insufficient_data

Note You need to log in before you can comment on or make changes to this bug.