Skip to main content.
home | support | download

Back to List Archive

Re: Segementation fault core dump (on merging)

From: Alex Lyons SercoAssurance-Winfrith Tel01305-202368 FAX01305-202194 <alex.lyons(at)>
Date: Mon Sep 23 2002 - 14:39:05 GMT
Bill & Others,

My earlier suggestion of using the last-modified date of the index itself if the 
file entry doesn't have a date wouldn't work for situations where more than one 
incremental indexes are being added to a master index in seperate stages, eg:
  swish-e -M incr1.i master.i newm.i ; mv newm.i master.i
  swish-e -M incr2.i master.i newm.i ; mv newm.i master.i
When the second merge command is run, "master.i" would have a newer modification 
date than "incr2.i"!

I guess this could be run as:
  swish-e -M incr2.i incr1.i master.i newm.i ; mv newm.i master.i
but there might be memory issues?

Perhaps it would be safer to say that the order of the files on the -M list 
determines the precedence for entries with no date (first file has highest 
precedence), and leave it up to the user to sort it out?

I'll shut up now and leave it to wiser developers to do whatever's easier or most 


>> >If you are merging two files that do not have a date (because the web
>> >server doesn't supply one) you still want the newer file -- so how do
>> >you pick which is the newer file?
>> If a filename stored in the index doesn't have a last-modified date, can you 
use the last-modified date 
>> if the index itself?  That would mean that the entry in the most recently 
created index would have 
>> precedence, which I guess is what most users would want.
>Ok, will do.  
>But this may change if a different database backend is used
>or with incremental indexing.  It's safer to make sure that there's a date
>if you will need it.  I suppose we could force a last modified data on all
>records when created, but I don't really like doing that.  Would want
>to flag that date as not a real date.
>Bill Moseley

  This e-mail and any attachments may contain confidential and/or
  privileged material; it is for the intended addressee(s) only.
  If you are not a named addressee, you must not use, retain or
  disclose such information.
  Serco cannot guarantee that the e-mail or any attachments are
  free from viruses.
  Serco Group plc. Registered in England and Wales. No: 2048608
  Registered Office: Dolphin House, Windmill Road,
  Sunbury-on-Thames TW16 7HT, United Kingdom.
Received on Mon Sep 23 14:42:37 2002