
> > There are still a lot of images with HASH in them,
> 
> Ok, I checked through them and found that 3174 are effected.

Sounds about right.

> That is a lot of affected files!!!

Yes.

> We need to develop a strategy for dealing with this. Ok, 
> Jonadab, could you advise us all as to the best way to conquer 
> and divide this task.

My plan, such as it is, runs roughly as follows:

1. I have one script (not sure if it's in CVS or not; I can
   put it in tonight if it's not) that is designed to look
   through all the .svg files in the current directory, find
   ones that contain "HASH" in them, and for each one look
   through upload.log and extract all the apparently-relevant
   input log entries and write them to a file that's named
   the same as the .svg file but with .log appended to the name.
   Thus, if there's a broken file foo.svg, this script creates
   foo.svg.log and writes in it all the relevant entries it can
   find in the upload log.  I *think* this script works, at
   least for the majority of cases, but there will be a few
   cases where for some reason it cannot find the relevant
   upload log entries, e.g. if the title and filename are
   HASHsomething so that it doesn't know what original title
   to look for in the log.  Those few can be left for now
   until the majority are done, and then figured out by hand
   subsequently; there won't be many, I think.
2. I have another script (not sure if this is in CVS either,
   but again, if not, it can be) that is *mostly* done, that
   is designed to read the .log files and trace the process
   that upload_svg.cgi would have done with that input and
   basically reproduce it, creating a repaired file, which
   will have -repaired.svg appended to its name, to avoid
   overwriting the original.  Thus, if there was foo.svg,
   which was broken, and the first script created foo.svg.log,
   this one creates foo.svg-repaired.svg or somesuch.
3. Someone will need to look over the repaired files created 
   by the second script and verify that they seem okay.
4. Then the original, b0rkened files can be replaced with
   the new repaired ones.

For files submitted anytime after 0.12 (i.e., any files submitted
for 0.13, 0.14, 0.15, or 0.16 before I repaired the upload script),
my plan is to re-process the incoming files, running the above
steps over them before processing, so that we will re-do what was 
done for those releases, only correctly.  Thus, release 0.16 will 
be, like the last two releases, based on 0.12 but with new images
added from all of the releases in the interim.  I hope that 0.16
is the last release I have to do that way, as otherwise it's going 
to get cumbersome reprocessing all those files every time :-)

Any images that were already corrupted with HASH keywords in
the 0.12 release are another matter.  They may have to be 
re-keyworded by someone.  However, the good news is, *only*
keywords seemed to be impacted by the hash bug until more
recently, so I don't think any of those are missing author
or title information.

> Also, are you sure that the "hash bug" is squished? 

Yes, assuming everyone uses the version of Metadata.pm that is 
in CVS, that particular bug is gone.  There may be other bugs,
but that one is toast.

> Hopefully, we can fix these images once and then that will 
> be that...

Yes, and then we can get on to worrying about the character set
issues again...

--
This message was sent using 3wmail.
Your fast free POP3 mail client at www.3wmail.com

