Bug 345541

Summary:	db2ldif -u or -s returns different number of processed entries.
Product:	[Retired] 389	Reporter:	Thomas Blanchin <tblanchin>
Component:	Command Line Utilities	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	low	Docs Contact:
Priority:	medium
Version:	1.0.4	CC:	benl, nhosoi
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-01-20 00:13:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	249650

Description Thomas Blanchin 2007-10-22 17:05:31 UTC

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-02 01:29:44 UTC

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 23:41:17 UTC

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-20 00:13:07 UTC

per bug council, closing w/insufficient_data