Hi, Alexandre, I forgot to give you the feedback and here it is. Sorry for not replying earlier.
On Jul 06 2015, Alexandre Detiste wrote: > 2015-07-06 14:11 GMT+02:00 Rogério Brito <[email protected]>: > > # cruft -d / -d /boot -r report.log --ignore /home --ignore /var --ignore > > /tmp > > /usr/lib/cruft/explain/USERS: 160: [: /usr/lib/cruft/cruft_find: unexpected > > operator > > /usr/lib/cruft/explain/USERS: 160: [: /usr/lib/cruft/cruft_find: unexpected > > operator > > now fixed: > https://github.com/a-detiste/cruft/commit/b38b19c74c3dd11812b2991dc04a8642395401c0. > > Can you please directly edit /usr/lib/cruft/common.sh and remove the > extraneous "$@" > to check that it solves your problem ? Yes, that solves it. Sorry for not diving too much into the code to find the issue and supplying you with a patch, but I've been in a hurry with lots of stuff to do. > I see you are using "--ignore /home", which is what well everybody should do > to avoid that /home got scanned *twice* only just to detect broken symlinks > & non-owned files. I didn't know that the current implementation of cruft did these things twice, which I guess that could be done in just one pass (that could be done with essentially a few lines with just a few calls to stat). Besides that, doing those things in two passes requires going to the disk twice, which is bad from both the latency and caching (if many files are to be scanned), especially if the system is constrained in memory (like my NAS with only 128MB of which there is essentially 10MB usable at any given time, due to the kernel reserving memory and other programs running). > (cruft computes a huge list with these items, another huge one without > these items but well all regular files, the compare the two.) Didn't know that. > I was really tempted to make it the default behaviour, but I don't want to > break users expectations either. Do a few releases of cruft and state (when the user executes the program) that the current behavior is going to be deprecated and changed in a future release with the "space" between the deprecation warning being one Debian release (i.e., jessie+1). > It's not like I can send a survey to "registrated customers" > to get a feeling of what they think about it. I also don't know my users think of my packages (but I am upstream only for programs that I *don't* have packaged in Debian, anyway). But for one that changes a lot (youtube-dl) what I usually do is to put behavior changes in the NEWS file. Note that a note in the NEWS file *may* be insufficient for the users, but a runtime warning that things are going to change is much more informative, *when* it can be done. > For cruft-ng (my rewrite of the shell/perl/c engine in C++); > I just never scan further that the first level in /home; > and avoid /tmp altogether. That sounds like a good plan, but please, state clearly the differences in behavior in the documentation. > Well, speed was priority & command lines are not implemented at all at > the moment, but the defaults are saner; Which is the good way to go. > and tool can be indirectly configured by tweaking mlocate's > /etc/updatedb.conf . Hummm, here we have a problem: not all users have even mlocate installed (it's one of the first packages that I purge from my systems whenever I install them). I wouldn't want to have a cron job running every day to update the list of files that I have. The "one time" hit of running cruft (or cruft-ng, or whatever) every now and then is acceptable, but the hit of running a cron job every day (or weekly or whatever) is not something that I like to have. But I guess that we can discuss these tangential points in another thread, so as to not pollute this but report. :) I'm happy to give you my intended usage patterns, so that you can incorporate them into cruft-ng. Thanks, -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
