[OPENDJ-7191] dsbackup purge --keepCount does not accept 0 as a value Created: 13/May/20  Updated: 29/May/20  Resolved: 18/May/20

Status: Done
Project: OpenDJ
Component/s: tools
Affects Version/s: 7.0.0
Fix Version/s: 7.0.0

Type: Bug Priority: Critical
Reporter: Ondrej Fuchsik Assignee: Ondrej Fuchsik
Resolution: Fixed Votes: 0
Labels: Verified

Epic Link: Backup and restore patterns
Story Points: 1
Dev Assignee: Cedric Tran-Xuan
QA Assignee: Ondrej Fuchsik


With 7.0.0-SNAPSHOT rev. 045f72e67ea I found out that I can't use 0 as a value for --keepCount parameter of dsbackup purge subcommand.

The tool subcommand doc says:

--keepCount {number of backups}
    The number of backups to keep per backend. Use this option to keep the n
    latest backups of each backend and delete the others. If n=0, all the
    backups will be removed

So the value 0 should be accepted but it is not. 

When 0 is used as a value the tool reports following error:

An error occurred while parsing the command-line arguments:  
The provided value "0" for argument --keepCount is not acceptable:  
The provided keepCount value 0 is unacceptable because it is below the lower bound of 1
See "dsbackup --help" to get more usage help

Comment by Ludovic Poitou [ 13/May/20 ]

Have you tried with the --force option?
It's supposed to allow you to delete all backups.
This said, the error message needs some improvements if it works with --force.

Comment by Ondrej Fuchsik [ 13/May/20 ]

I will try but --force is dedicated for --olderThan only.



--force does not help

Comment by Cedric Tran-Xuan [ 14/May/20 ]

That's a bug due to a constraint that have been left for the `–keepCount` option. Sorry, about that.
It was agreed the `–keepCount 0` was possible without `–force` (https://bugster.forgerock.org/jira/browse/OPENDJ-1310?focusedCommentId=186400&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-186400)

Comment by Ondrej Fuchsik [ 18/May/20 ]

Verified with 7.0.0-SNAPSOT rev. ff04c9739d7 .

Generated at Tue Nov 24 00:43:20 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.