After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 43913 - Searching by file size can include non-matching results
Searching by file size can include non-matching results
Status: RESOLVED DUPLICATE of bug 43920
Product: nautilus
Classification: Core
Component: File Search Interface
0.x.x [obsolete]
Other Linux
: Normal normal
: ---
Assigned To: Rebecca Schulman
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2000-10-20 18:20 UTC by John Sullivan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description John Sullivan 2001-09-10 00:46:21 UTC
To reproduce:
(1) Launch Nautilus
(2) If necessary, change the search preference in the user level settings dialog
to "search for files by name and attributes"
(3) Press Find button
(4) Change the criterion-type popup (first one) from "name" to "size"
(5) Type in 2000 into the text field. It now says you're looking for files
larger then 2000 K.
(6) Press "Find Them" button, wait for search results to appear
(7) Click "Size" column header to sort results by size; click it again to flip
the order so the smallest items are first.

When I do this, the first item listed is /tmp/medusa-indexd-log, which is 57
bytes. Then come two copies of libgtkxmhtml.so.1.0.1, in different places, each
of which is 1.3M. Finally I get 170 other items that are in fact 2.0M or larger.
These first three should not have been in the search results and indicate some
problem with the by-size filtering. Maybe these files were >2.0M when the index
was made but got smaller since then?



------- Additional Comments From rebecka@eazel.com 2000-10-20 14:45:46 ----

I would suspect that John is right about that some returned items will
no longer match their search criteria.  In fact, this will be true for every
criterion except name, in which case, the file will not get returned, because we
can't find it anymore.

Perhaps the way to fix this bug is to do an indexed search, but also post
check that the item still fits the criteria?  this, unfortunately, would be
an expensive solution.  We could probably limit the checks to files that
had changed since the last index time.  I need to think a little bit about
the right approach to this problem.



------- Additional Comments From darin@bentspoon.com 2000-10-20 16:21:05 ----

I don't think the idea that the files changed sizes since the indexing explains 
/tmp/medusa-indexd-log. Is anyone suggesting that was larger than 2.0 MB? Also, 
what are the chances that the size of libgtkxmhtml.so.1.0.1 changed? Maybe, but it 
sounds fishy to me.

That having been said, I do like the rest of Rebecka's thoughts about refiltering files 
(since the index may not be up to date).



------- Additional Comments From rebecka@eazel.com 2000-11-02 15:34:32 ----

I think the indexd log could actually be that large, but you are right that
gtkxhtml changing in size that much  does seem a bit weird.

In any case, if we are going to check for whether properties still match,
we should probably do this for all items (it's going to look really silly
to have only some search results marked with the emblem we searched for,
for example).  It should probably be medusa's responsibility, but if that is 
the case, we going to bring up new performance issues, especially with large,
uncancelled searches.

Perhaps we should look more into the size issue as part of the test harness.
I'd like to see a reproducible case of size being searched for incorrectly
before deciding that is a problem worth dealing with.



------- Additional Comments From rebecka@eazel.com 2000-11-21 23:49:31 ----

This was fixed as part of the fix for 3920

*** This bug has been marked as a duplicate of 43920 ***



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:46 -------