Hi Ward,

Thursday January 02 2014 05:46, you wrote to me:

 WD> Ulrich,
 US>> the search for segment files probably requires a complete rewrite,
 WD> As you know, the numbering poses no problem here (as in 80+% of the
 WD> nodelist) so "If it isn't broke, don't fix it".

fine if it works for you  =;)

what I have in mind is similar to the ALLOWunpub switch ...

having 2 routines available ...

a. if no switch is set, use old routines, and live with the flooded
   segmentfiles working dir or living with the missed segments in
   strict filename searches
b. a new routine, that is capable to search for a given filemask
   of one segment (for each segment) no matter of fileextension
    1. analyse file date
    2. analyse file daynumber extension
    3. analyse admin line (if available)
   If multiple valid segments are found, bring them in a chronicle order,
   with cleanup, leave 1 or 2 'current' segments, update the latest segment
   to current daynumber extension

   the advantage: every daynumber segment counts, no more missing segments
   caused by wrong daynumbers, no more yearly wrapping problems, as the
   analysed segments have to be sorted in an internal table by datetime
   before further processing, no more time limiting of 'old' segments
   no more dumb daynumber calculation for x weeks, also mixed filenumber
   extensions are possible. Verification by the first admin line of each
   segment (if possible)

Another bug report (don't know if its still fixed) mentions a problem with
packed segments. So pre-processing analyse routine also can check packed
segments, can unpack them and include the extracted files to the analyse
processing. And in the case a packed filename extension doesn't match to the
filename included (eg extension is z03 and tempted to believe that the file is
of current date, but the segment is from day# 203 of year 2011 (probably last
x03 filename extension that matches x03 numbering schema - pack *.?03

similar routine I've implemented in some pointlist checker and processing
tools approx 15-20 years ago ...


              extension   filedate    admin line  valid  result   datetime
                                                  crc.ok
region56.003   current     current     current     yes   4     20131231210000
region56.361  not current not current not current  yes   1     20131224210700


extension calculation, upcoming Friday ->  003
  -> valid are all daynumbers between 361 and 003

datetime of upcoming Friday -> 20140103
  -> filedate in range 20140103 down to 20131227

admin line  segment for daynumber/date ->  003, 2014-01-03
  -> matches exactly

admin line crc matches nodelist-crc
  -> matches exactly

now you can programticly calculate a valid current segment
sort date desc ->  20131231, 20131224  -> use file 20131231



 WD>  \%/@rd
 WD>  $ Origin: Many Glacier / Protect - Preserve - Conserve (2:292/854)

regards, uli   ;-)

---
 * Origin: AMBROSIA - Frankfurt/Main - Germany (2:240/1120)