Re: [htdig] Startday bug?

[Andrej <li...@va...>]

Hello Bill,

It was a bug and the patch posted in your mail fixed it.

Thank you!

Andrej.

William R. Knox wrote:

>Andrej,
>Take a look at this message (and patch, you'll be happy to hear) posted by
>Gilles around this time last year in response to my bug report about the
>very same issue. This should do it for you. Good luck.
>
>			Bill Knox
>			Lead Operating Systems Programmer/Analyst
>			The MITRE Corporation
>
>On Thu, 15 Jan 2004, Andrej wrote:
>
>
>>Date: Thu, 15 Jan 2004 18:48:04 +0100
>>From: Andrej <li...@va...>
>>To: htd...@li...
>>Subject: [htdig] Startday bug?
>>
>>Hello,
>>
>>I'm using the startday variable to find files that are not older than 40
>>days. Now, there is one file in the file system, which has been created
>>on 10th Jan. 2004. ht://Dig can't find this file. Other files are from
>>2003, and they can be found, if the modification time in fs is not older
>>than 40 days.
>>
>>When I set the startday value on 10, the file created in 2004 is found.
>>Is it possible that there is a bug if a value in startday is containing
>>a value that goes in the previous year?
>>
>>The query that I send to htsearch is:
>>config=staging/de_press&endday=&endmonth=&endyear=&startday=-40&startmonth=&startyear=&matchesperpage=1000&words=%2A&sort=date&restrict=/press&exclude=sitemap&page=1
>>
>>The ht://Dig Version is 3.1.6
>>
>>
>>Sorry about my english,
>>
>>Andrej.
>>
>>
>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>ht://Dig general mailing list: <htd...@li...>
>>ht://Dig FAQ: http://htdig.sourceforge.net/FAQ.html
>>List information (subscribe/unsubscribe, etc.)
>>https://lists.sourceforge.net/lists/listinfo/htdig-general
>>
>>
>
>
>------------------------------------------------------------------------
>
>From gr...@sc... Thu Jan 15 13:01:14 2004
>Date: Wed, 22 Jan 2003 16:57:46 -0600 (CST)
>From: Gilles Detillieux <gr...@sc...>
>To: William R. Knox <wk...@mi...>
>Cc: fun...@si...,
>     "ht://Dig mailing list" <htd...@li...>
>Subject: Re: [htdig] Bug in startday code, v. 3.1.6 (patched) (fwd)
>
>According to William R. Knox:
>
>>I am still seeing this problem, and have come across another clue. It
>>works fine if a relative endday, such as -1, is also passed. In reading
>>the bugs database closer, it also appears that bug 578570 may also be
>>related.
>>
>>I have confirmed this bug by searching on the htdig site with the
>>following three GET strings sent via a telnet session - note how the final
>>two hit counts differ:
>>
>>Search for 'startday', no date range (returns 50 hits)
>>---
>>GET /cgi-bin/htsearch?method=and&words=startday HTTP/1.1
>>Host: www.htdig.org
>>
>>Search for 'startday', set startday to -60 (returns 0 hits)
>>---
>>GET /cgi-bin/htsearch?method=and&words=startday&startday=-60 HTTP/1.1
>>Host: www.htdig.org
>>
>>Search for 'startday', set startday to -60 and endday to -1 (returns 1 hit)
>>---
>>GET /cgi-bin/htsearch?method=and&words=startday&startday=-60&endday=-1 HTTP/1.1
>>Host: www.htdig.org
>>
>>Unfortunately, my C++ coding is non-existent, but the line which seems to
>>me to be suspect is in Display.cc, line 1295-6:
>>    else if (!reldate)
>>        enddate.tm_year = endoftime->tm_year;
>>
>>Could this somehow be getting set to the same year as the
>>startdate.tm_year?
>>
>
>... and on Tue, 7 Jan 2003 ...
>
>>I believe that I have come across a bug in the startday code in version
>>3.1.6 (I have applied the metadate.0 patch and the timet_enddate.1 patch).
>>Briefly, using a negative number in the startday that overlaps a year
>>boundary (i.e. using a number greater than -7 today, 1/7/03) causes only
>>entries for the previous year to be displayed. Here is an example:
>>
>
>Whoops!  Mea culpa.  When I added the support for relative dates, I
>didn't realize that the added localtime() calls would clobber the data
>structure that endoftime is set to point to.  Surprisingly, this doesn't
>affect all systems, but I guess some implementations of localtime share
>the same return data structure as gmtime, and some don't.
>
>Here's a fix, which I'll call timet_enddate.2, and which overrides
>the timet_enddate.1 patch in the archives.  It saves a copy of the
>gmtime return structure so it's not clobbered.  Plus it includes
>Robert Marchand's earlier fix for the problem in 3.1.6's handling of
>the end date in the date range support.  (The test to see if the end
>date was set was wrong, so htsearch assumed it always had to check
>the date for each match, which caused the extra overhead described in
>http://www.htdig.org/FAQ.html#q5.10)
>
>Apply this patch in your main htdig-3.1.6 source directory using the
>command:  patch -p0 < this-message-file
>
>If you've already applied timet_enddate.1, don't worry: the second hunk
>of this patch will fail (because it's already been applied), but the
>first should apply fine and all should work fine after that.
>
>--- htsearch/Display.cc.orig	Thu Jan 31 17:47:18 2002
>+++ htsearch/Display.cc	Tue Jan 21 15:46:19 2003
>@@ -1148,6 +1148,8 @@ Display::buildMatchList()
> 
>     // find the end of time
>     endoftime = gmtime(&eternity);
>+    tm eterni_tm = *endoftime;
>+    endoftime = &eterni_tm;
> 
>     if(dategiven)    // user specified some sort of date information
>       {
>@@ -1407,7 +1409,7 @@ Display::buildMatchList()
> 
> 	// New check added on whether or not we need to check date ranges - MG
> 	if (date_factor != 0.0 || backlink_factor != 0.0 || typ != SortByScore
>-	    || timet_startdate > 0 || enddate.tm_year < endoftime->tm_year)
>+	    || timet_startdate > 0 || timet_enddate < eternity)
> 	  {
> 	    DocumentRef *thisRef = docDB.FindCoded(thisMatch->getURL());
> 	    if (thisRef)   // We better hope it's not null!
>
>