INI duplicate keys in the same section should produce a parsing error

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/594

• Created at 2010-07-30 00:44:35 by dpal
• Closed as Fixed
• Assigned to dpal

---

The INI file:

 [section]
 k1=v1
 k1=v2

should produce an error.

Comments

---

Comment from dpal at 2010-07-30 00:45:23

Alternatively we can provide an argument to control what to do in this case but I am not sure what is best. Thoughts?

---

Comment from dpal at 2010-07-30 00:45:23

Alternatively we can provide an argument to control what to do in this case but I am not sure what is best. Thoughts?

---

Comment from dpal at 2010-07-30 00:45:23

Alternatively we can provide an argument to control what to do in this case but I am not sure what is best. Thoughts?

---

Comment from sgallagh at 2010-07-30 16:40:28

In this case, traditionally the second option would just replace the first.

---

Comment from sgallagh at 2010-07-30 16:40:28

In this case, traditionally the second option would just replace the first.

---

Comment from sgallagh at 2010-07-30 16:40:28

In this case, traditionally the second option would just replace the first.

---

Comment from dpal at 2010-07-30 16:44:12

Replying to [comment:2 sgallagh]:

In this case, traditionally the second option would just replace the first.

But for the dry run case I think there should be a way to detect it as an error.

So I see following options:

- Overwrite (default)
- Return error 
- Ignore duplicates and get only the first

Makes sense?

And it seems that the same options should be used in the merge call.

---

Comment from dpal at 2010-07-30 16:44:12

Replying to [comment:2 sgallagh]:

In this case, traditionally the second option would just replace the first.

But for the dry run case I think there should be a way to detect it as an error.

So I see following options:

- Overwrite (default)
- Return error 
- Ignore duplicates and get only the first

Makes sense?

And it seems that the same options should be used in the merge call.

---

Comment from dpal at 2010-07-30 16:44:12

Replying to [comment:2 sgallagh]:

In this case, traditionally the second option would just replace the first.

But for the dry run case I think there should be a way to detect it as an error.

So I see following options:

- Overwrite (default)
- Return error 
- Ignore duplicates and get only the first

Makes sense?

And it seems that the same options should be used in the merge call.

---

Comment from dpal at 2010-07-30 19:43:40

Fields changed

milestone: NEEDS_TRIAGE => Tools 1.0

---

Comment from dpal at 2010-07-30 19:43:40

Fields changed

milestone: NEEDS_TRIAGE => Tools 1.0

---

Comment from dpal at 2010-07-30 19:43:40

Fields changed

milestone: NEEDS_TRIAGE => Tools 1.0

---

Comment from dpal at 2012-01-19 03:25:59

Fields changed

rhbz: => 0

---

Comment from dpal at 2012-01-19 03:25:59

Fields changed

rhbz: => 0

---

Comment from dpal at 2012-01-19 03:25:59

Fields changed

rhbz: => 0

---

Comment from dpal at 2012-09-26 21:43:00

This is not handled by merge and search code. One can force this situation to produce an error, just overwrite, just preserve first one or allow duplicates and then fetch them one by one.

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

---

Comment from dpal at 2012-09-26 21:43:00

This is not handled by merge and search code. One can force this situation to produce an error, just overwrite, just preserve first one or allow duplicates and then fetch them one by one.

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

---

Comment from dpal at 2012-09-26 21:43:00

This is not handled by merge and search code. One can force this situation to produce an error, just overwrite, just preserve first one or allow duplicates and then fetch them one by one.

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

---

Comment from dpal at 2012-12-18 04:14:10

Patches have been pushed.

design: =>
design_review: => 0
fedora_test_page: =>
resolution: => fixed
status: new => closed

---

Comment from dpal at 2012-12-18 04:14:10

Patches have been pushed.

design: =>
design_review: => 0
fedora_test_page: =>
resolution: => fixed
status: new => closed

---

Comment from dpal at 2012-12-18 04:14:10

Patches have been pushed.

design: =>
design_review: => 0
fedora_test_page: =>
resolution: => fixed
status: new => closed

---

Comment from dpal at 2017-02-24 14:34:18

Metadata Update from @dpal:

• Issue assigned to dpal
• Issue set to the milestone: Tools 1.0