]> dgit.raspbian.org Git - git-annex.git/commit
prevent numcopies or mincopies being configured to 0
authorJoey Hess <joeyh@joeyh.name>
Mon, 28 Mar 2022 19:19:52 +0000 (15:19 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 28 Mar 2022 19:20:34 +0000 (15:20 -0400)
commitd266a41f8d191d3b3322ed5a6bb85bb8d2f53166
tree2c23d22fea11efde5b850491f99ace84b4bc245c
parentfdcb14d475f2b4e5735bcc3016fa4fe83dfb1ef4
prevent numcopies or mincopies being configured to 0

Ignore annex.numcopies set to 0 in gitattributes or git config, or by
git-annex numcopies or by --numcopies, since that configuration would make
git-annex easily lose data. Same for mincopies.

This is a continuation of the work to make data only be able to be lost
when --force is used. It earlier led to the --trust option being disabled,
and similar reasoning applies here.

Most numcopies configs had docs that strongly discouraged setting it to 0
anyway. And I can't imagine a use case for setting to 0. Not that there
might not be one, but it's just so far from the intended use case of
git-annex, of managing and storing your data, that it does not seem like
it makes sense to cater to such a hypothetical use case, where any
git-annex drop can lose your data at any time.

Using a smart constructor makes sure every place avoids 0. Note that this
does mean that NumCopies is for the configured desired values, and not the
actual existing number of copies, which of course can be 0. The name
configuredNumCopies is used to make that clear.

Sponsored-by: Brock Spratlen on Patreon
16 files changed:
Annex/Drop.hs
Annex/NumCopies.hs
Assistant/WebApp/Configurators/Preferences.hs
CHANGELOG
CmdLine/GitAnnex/Options.hs
Command/Drop.hs
Command/Fsck.hs
Command/MinCopies.hs
Command/NumCopies.hs
Command/Vicfg.hs
Limit.hs
Logs/NumCopies.hs
Types/GitConfig.hs
Types/NumCopies.hs
doc/git-annex-common-options.mdwn
doc/git-annex.mdwn