Your message dated Mon, 21 Sep 2015 13:33:39 +0200
with message-id
<CADsTwjJD=foedmjzo+m0c7djkj4zvajupb8tcqkdmtjs6nw...@mail.gmail.com>
and subject line Fwd: #50731: cruft: uses too much disk space
has caused the Debian Bug report #50731,
regarding cruft: uses too much disk space
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
50731: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=50731
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cruft
Version: 0.9.5
Severity: wishlist
The way cruft is designed causes it to use rather a lot of disk
space. For example, when producing a report on my fairly
small system (filesystems 1GB, 250MB, 250MB) it put 15MB
of stuff into /var/spool/cruft/.
Surely this could be reduced somewhat by a cleverer algorithm?
For example, /usr/lib/cruft/explain/dev is just a 'find /dev'
command. This means that all the files in /dev are listed
in a file in the spool. It would be better to allow something
like a wildcard or regexp syntax so you didn't have to list
all the files in /dev explicitly.
This gets much worse if you use this strategy for directories
like /usr/local, naturally.
I think that a better way to do the job would be to first
create the files to be used to filter the file names, as we
do now (expl_* and need_*), but then to do the weeding out of
'OK' files on the fly as part of the pipeline 'find $DRIVE...',
rather than creating large file_* files and then processing
them.
Obviously this would be quite a bit of work :->
Peter Maydell
--- End Message ---
--- Begin Message ---
The average file count of files under /
minus files under /home as not increased
that much since 1999; while RAM availability
has continued to increase exponentially.
This bug is now irrelevant in 2015.
cruft-ng C rewrite doesn't spool anything at all,
it keeps everything in memory
and works fine even on a Raspberry Pi 1.
(and is 5x faster that cruft)
So closing this bug instead of keeping
"wontfix" forever.
--- End Message ---
