GNU bug report logs - #47353
Numbered backups also need kept-new-versions else will grow out of control

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47353 in the body.
You can then email your comments to 47353 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dan Jacobson <jidanni <at> jidanni.org>
To: bug-coreutils <at> gnu.org
Subject: Re: Numbered backups also need kept-new-versions else will grow out of
 control
Date: Wed, 24 Mar 2021 07:43:01 +0800

Or (info "(coreutils) Backup options") should "admit" that "Numbered
backups need to be trimmed occasionally by the user, lest the fill up
the disk."

Message #8 received at 47353 <at> debbugs.gnu.org (full text, mbox):

From: Chris Elvidge <celvidge001 <at> gmail.com>
To: Dan Jacobson <jidanni <at> jidanni.org>, 47353 <at> debbugs.gnu.org
Subject: Re: bug#47353: Numbered backups also need kept-new-versions else will
 grow out of control
Date: Wed, 24 Mar 2021 09:49:29 +0000

On 23/03/2021 11:43 pm, Dan Jacobson wrote:
> Or (info "(coreutils) Backup options") should "admit" that "Numbered
> backups need to be trimmed occasionally by the user, lest the fill up
> the disk."
> 
> 
> 
> 

So 'use common sense to limit disk space used' has to be stated in the 
manual?

-- 

Chris Elvidge

Message #11 received at 47353 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Chris Elvidge <celvidge001 <at> gmail.com>
Cc: 47353 <at> debbugs.gnu.org
Subject: Re: bug#47353: Numbered backups also need kept-new-versions else
 will grow out of control
Date: Thu, 25 Mar 2021 02:52:49 +0800

>>>>> "CE" == Chris Elvidge <celvidge001 <at> gmail.com> writes:

CE> So 'use common sense to limit disk space used' has to be stated in the
CE> manual?

Hmmm, yes.
And also mention in the manual that e.g., emacs has methods to trim
these automatically, but coreutils hasn't implemented them yet.

Else users will write elaborate programs to do it, thinking that nobody
thought about it yet.

Message #14 received at 47353 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Dan Jacobson <jidanni <at> jidanni.org>
Cc: 47353 <at> debbugs.gnu.org
Subject: Re: bug#47353: Numbered backups also need kept-new-versions else
 will grow out of control
Date: Wed, 24 Mar 2021 18:25:56 -0600

tag 47353 + notabug
close 47353
thanks

Dan Jacobson wrote:
> Or (info "(coreutils) Backup options") should "admit" that "Numbered
> backups need to be trimmed occasionally by the user, lest the fill up
> the disk."

If the user has asked for them then any decision of the disposition of
them is up to the user.  If the user fills up their storage with them
then surely the user who created them will know what they did and will
be in the best position to decide what to do.

This type of thing is really both too general to document in detail
and too specific to document in detail at the same time.  It targets a
very specific thing, filling up the disk, with a very general purpose
action, copying files.  Both of which are plain actions not hidden or
subtle.  Consuming storage space by making copies is the primary
purpose of the cp command.

> And also mention in the manual that e.g., emacs has methods to trim
> these automatically, but coreutils hasn't implemented them yet.

Although cp, mv, and ln, may have used the same format as emacs for
the creation of backup files that does not mean that they *are* emacs
or that emacs is the preferred editor for users of cp and mv or that
knowledge of emacs is needed to use them.

I use Emacs and find it a superior editor for creating customized
domain specific editors.  But I don't think it should be referenced
from cp because the Emacs documentation is *HUGELY* more complicated.
If a new user is reading documentation on how to use cp then being
directed to climb the learning curve of Emacs would be way too much to
ask!  There is a user who I think would file a bug that it is too much
to ask if it were done that way.

The better thing to mention in relation to cp would be rm as those
would be natural siblings.  But they are actually siblings already.
So there seems no further need to cross-reference them additionally
redundantly again redundantly.

I am marking the ticket as closed as there seems nothing to actually
do here.  But as always more discussion is welcome and if it is
determined that something should be done then the ticket may be opened
again to track it.

Bob

Message #23 received at 47353 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 47353 <at> debbugs.gnu.org
Subject: Re: bug#47353: Numbered backups also need kept-new-versions else
 will grow out of control
Date: Thu, 25 Mar 2021 09:21:18 +0800

All I am saying is 'to acknowledge the hazards'... 'Advisory on
prolonged use'. 'Note about health effects of unattended use.'

For all the user knows reading
(info "(coreutils) Backup options")
maybe numbered backups even just means one backup, numbered ...1.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
Cc: Coreutils <bug-coreutils <at> gnu.org>, Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#47353: Numbered backups also need kept-new-versions else
 will grow out of control
Date: Thu, 25 Mar 2021 06:43:29 -0700

On 2021/03/23 16:43, Dan Jacobson wrote:
> Or (info "(coreutils) Backup options") should "admit" that "Numbered
> backups need to be trimmed occasionally by the user, lest the fill up
> the disk."
>   
---
Perhaps a scheme, similar, or duplicating that in logrotate would
be useful where older versions can be limited by count and/or age?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.