bug#47353: Numbered backups also need kept-new-versions else will grow out of control
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.
bug#47353: Numbered backups also need kept-new-versions else will grow out of control
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
bug#47353: Numbered backups also need kept-new-versions else will grow out of control
> "CE" == Chris Elvidge 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.
bug#47361: mv: extended attributes discarded when moving to a different volume on macOS
Hello :) I've been using Homebrewed coreutils on my Mac for a while, and recently switched to MacPorts. With both of these package manager, the version of `mv` that is built will discard extended attributes when moving an item from one volume to another, though moving within the same volume the attributes are retained (I assume because here moving is done by simply editing an inode). The `mv` version that is bundled with OS X does not have this shortcoming. My testing with Ubuntu also shows that this is not an issue there. I reported the bug to MacPorts, but was told that this is likely an upstream problem, so I should take it here :) Here's to hoping that's true :D To reproduce (here with MacPorts, coreutils 8.32. Volumes are JHFS+): daniel@titanic > xattr -w test fisso LICENSE daniel@titanic > xattr -p test LICENSE fisso daniel@titanic > which mv mv: aliased to /bin/mv daniel@titanic > mv LICENSE /Volumes/Scratch daniel@titanic > xattr -p test /Volumes/Scratch/LICENSE fisso daniel@titanic > /opt/local/libexec/gnubin//mv /Volumes/Scratch/LICENSE . daniel@titanic > xattr -p test LICENSE xattr: LICENSE: No such xattr: test Cheers, Daniel
bug#47353: Numbered backups also need kept-new-versions else will grow out of control
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
