Here is a patch which changes a bit the behavior of the portage-utils 'file' applet wrt paths involving symlinks. The two things i didn't like were: 1) incoherent behavior when querying relative paths: % qfile /usr/lib/sendmail mail-mta/qmail (/usr/lib/sendmail) % cd /usr/lib % qfile ./sendmail net-mail/mailwrapper (/usr/sbin/sendmail) This one is because 'realpath($PWD/query)' is used to resolve relative paths, and "/usr/lib/sendmail" is a symlink to "/usr/sbin/sendmail" installed by qmail. ==> a solution is to call 'realpath(dirname($PWD/query))' instead. This way, the result is always the owner of the symlink, and not the owner of its target. 2) difficulty for finding owners of some file: % qfile /var/lib/xkb/README.compiled (no result) % ls -l /usr/share/X11/xkb/compiled lrwxrwxrwx 1 root root 12 mar 23 15:18 /usr/share/X11/xkb/compiled -> /var/lib/xkb % qfile /usr/share/X11/xkb/compiled/README.compiled x11-base/xorg-server (/usr/share/X11/xkb/compiled/README.compiled) Here, the file (README.compiled) has been installed through a symlink, and that's why the first query doesn't find its owner. There can be several paths leading to a file, but qfile currently only knows one (the one from the corresponding CONTENTS entry). Because of this limitation, it's impossible to use qfile for accuratly finding, for instance, orphan config files, or conflicting files installed by several packages, and this is quite unfortunate. ==> a solution is to also check the 'realpath(dirname(entry))'. Sure, calling realpath() on all entries would have an unacceptable cost. But it can be done only where basename() as already been verified, having almost no impact on the overall performances. The patch i will attach implements this two ideas. The two bigest chunks are: * in qfile(), change the logic of entry checking: - check basenames first (necessary anyway, and may be enough when searching a single file name) - then check dirname(query) against dirname(entry) - then check realpath(dirname(query)) against dirname(entry) - then check realpath(dirname(query)) against realpath(dirname(entry)) Note that the prototype of the function is changed to take separate arguments for basename(query), dirname(query), and realpath(dirname(query)). * in qfile_main(), prepare some arrays of basename(query), dirname(query), and realpath(dirname(query)), to avoid recalculating them 1500 times. Also take care there of adding $PWD for relative path, thing like that. Once applied, i get the results i was expecting on the two above-cited test cases: % cd /usr/lib % qfile ./sendmail mail-mta/qmail (/usr/lib/sendmail) % qfile /var/lib/xkb/README.compiled x11-base/xorg-server (/usr/share/X11/xkb/compiled/README.compiled)
Created attachment 84676 [details, diff] qfile-0.1.15-path_checking_enhancements.patch
Created attachment 84734 [details, diff] qfile-0.1.15-path_checking_enhancements.patch Removed a few useless strdup/strcpy.
Created attachment 86743 [details, diff] qfile-path_checking_enhancements.patch rediffed for 0.1.17
Oh sorry man I/we overlooked this. SpanKY: review this patch please.
Created attachment 88898 [details, diff] qfile-path_checking_enhancements.patch Rediffed for 0.1.18. Also changed some buffer sizes from PATH_MAX to _Q_PATH_MAX.
SpanKY: ping? Sorry if it sounds like bugspaming (ok, it is...), but i would really appreciate if you could review this patch. I'm even more convinced it is useful now that i have seen someone on gentoo-user-fr@ who was about to delete his /usr/X11R6/lib64 because qfile was showing it orphan... http://article.gmane.org/gmane.linux.gentoo.user.french/3770/
(In reply to comment #6) > SpanKY: ping? > > Sorry if it sounds like bugspaming (ok, it is...), but i would really > appreciate if you could review this patch. I'm even more convinced it is > useful now that i have seen someone on gentoo-user-fr@ who was about to delete > his /usr/X11R6/lib64 because qfile was showing it orphan... > http://article.gmane.org/gmane.linux.gentoo.user.french/3770/ > I know spanky has been very busy as of late.. I know you have submitted other good bug fixes. So I'll make a deal with you.. If you let me add you to the portage-utils@gentoo alias I'll add the patch with minor review and cut a new release with it in it. If any bugs show up you get to fix them.. Deal??
(In reply to comment #7) > If you let me add you to the portage-utils@gentoo alias I'll add the patch > with minor review and cut a new release with it in it. If any bugs show > up you get to fix them.. > Deal?? Ok, deal, i'll do my best to help with bugs which enter my mailbox. Thanks. Oh, and btw, before you do a new release, could you have a look on bug #139772 too? Don't worry, the patch there is really short :)
Thanks for the patch, it found that /usr/X11R6/qt/3/bin/lrelease belongs to qt while the current version did not. I've looked at the code and found two memory leaks. See Lines 227 and 230: if (chdir(portroot)) errp("could not chdir(%s) for ROOT", portroot); if (chdir(portvdb) != 0 || (dir = opendir(".")) == NULL) return EXIT_FAILURE;
(In reply to comment #9) > I've looked at the code and found two memory leaks. See Lines 227 and 230: > > if (chdir(portroot)) > errp("could not chdir(%s) for ROOT", portroot); > > if (chdir(portvdb) != 0 || (dir = opendir(".")) == NULL) > return EXIT_FAILURE; > Good catch, thanks. Moving them before the arrays allocation will do the trick (this part doesn't rely on the cwd, since $PWD is used to get absolute paths). I will attach an updated patch.
Created attachment 91296 [details, diff] qfile-path_checking_enhancements.patch
Ok this patch adds on average about 7s to a 'time qfile /bin/*' on my local box (144 things). I've checked it into CVS anyway and will request that you submit any optimizations you come up with over time. I've created the bugzilla entry portage-utils and will reassign the pkg and bugs to it.
portage-utils-0.1.19 released
