[Netarchivesuite-users] Uploading files

aponb at gmx.at aponb at gmx.at
Wed Oct 21 13:59:53 CEST 2009


Thanks for these detailed instructions, which are very helpfull!
In my case the harvester-version was the correct one (it was not 
possible to unzip the version in the archiv). So A2 was my topic.
I could do the cleaning with the provided User-Interface. It took some 
days to get the reply of the programm, but finally it worked. After that 
I could upload the file with the upload.sh without problems.

Thanks for your help!
Regards
a.

> This seems to me to be that the file was priviously uploaded (perhaps not all the way) so the admin.data knows about the file - but the file is still on the harvester and has now changed (e.g. a bit has flipped).
>
> You should
> 1. Check your archive (do you have multiple locations ?) - is the file there ?
> 2. If "yes" to (1) - what is the checksum of the file in the archive ?
> 3. Check admin.data - what does it know about the file (grep [filename] admin.data)
> 4. If its the case that the archive already have the file and the archive-file is different from the file on the harvester (It seems to be the case) you need to decide.
>   - A) Is the archive-file or the temp-file on the harvester the right one
>   - A1) if you decide that the archive-file is the right one you could delete the harvester-file - maybe copy the archive-version back to the harvester and do another upload with the command-line tool to ensure that your correct file is at all locations (if you use multiple locations)
>   - A2) if you decide that the harvester-version is the correct one (if the upload for some reason failed during file-transfer) you need to do some cleaning
>   - A2-1) delete the file from the archive
>   - A2-2) I think this should work: run bit-preservation filestatus (do you use the archive-module of NetarchiveSuite) - the file should be found as missing - you can then with the interface mark it as FAILED - and your upload from command-line should work
>   - A2-3) You could also (but not initially recommended): Stop the ArcRepository Application - edit admin.data and delete all lines containing the filename - be careful with this one - e.g. make a backup copy of the file before editing. This method is the only one if A2-2) does not work.
>
> I hope this will help you. You have reached a very rare situation where an ARC-file on disk have changed - either in your archive or on your harvester machine. A good example of why you need multiple copies of files archived as soon as possible after the harvest so that exactly this does not happen.
>
> best
> Bjarne Andersen
>
>   



More information about the NetarchiveSuite-users mailing list