Open geo-mac opened 4 years ago
Just a follow-up note to report that I got the job running by destroying the offending Eprint (Archivematica ID 26) and destroying the record of it within the UI. However, the job later failed at 941 and reported the same error. So, the job got significantly further but still encountered problems. Incidentally, the offending file was simply an HTML file. One has to assume that 941 is also corrupted.
I guess it would make sense for the job to skip over these sorts of files and report them afterwards for possible manual intervention.
Some great work going on here -- thanks. Things are working pretty well on our EPrints test instance but we have noted some inconsistencies, notably that the
process_transfer
job is failing and reporting a 'copy failed' error. The job actually processes and exports all eprints with Arhicvematica IDs 1-25 successfully but then fails on ID 26.. I'm not identifying any issue with line 77 of this file and seems to validate pretty much correctly at perlcritic which is useful to know, because my Perl is not good. Here's the verbose report:The other curious aspect to this is that the Archivematica report within the Eprints backend is reporting 26 (and hundreds of others) as having been successful. However, I know from the command line -- and from observing the export folder at /opt/eprints3/archives/strathprints/archivematica -- that this is not true. Only 1-25 have been exported.
26 may be a corrupt file and I will experiment by removing it altogether from our testing to determine whether this is causing the job to fail. But this still leaves open the issue with the backend reporting. Any ideas folks?