Closed dazza-codes closed 10 years ago
[sdr2service@sdr-services-test ~]$ sha256sum /services-disk/replica-cache/sdr/bb020sf5359-v0001/data/bb020sf5359-v0001.tar
63dc4fe31dcc44f6c9c8391573ecd739b4d84cff1599fd12e48dd9d66da35cf0 /services-disk/replica-cache/sdr/bb020sf5359-v0001/data/bb020sf5359-v0001.tar
[sdr2service@sdr-services-test ~]$ cat /services-disk/replica-cache/sdr/bb020sf5359-v0001/manifest-sha256.txt
91746fb78b03cbf7f7f288bd950d60f4380ea307d06d43c40fd6120f525866c2 data/bb020sf5359-v0001.tar
63dc4fe31dcc44f6c9c8391573ecd739b4d84cff1599fd12e48dd9d66da35cf0 data/bb020sf5359-v0001.tar
Last one is correct.
Replicated this bug by accessioning the same druid twice on the -test platform. This involves first removing all content for the druid from dor, sdr, etc. However, this 'nuke' process does not remove any content from the replica-cache. So, a solution for this is to do that.
This almost never going to happen in practice, because duplicate accessioning is prevented. However, it may be important to ensure that the replica robot itself cannot create duplicate content. This could be important when replica content may be sourced from multiple inputs, not just the accessioning workflow.
The sdrIngestWF will now raise an exception when a duplicate replica could overwrite an existing replica.
File manifest should contain info about the kind of checksum (md5, sha256, etc.). What is going on with this one? Two diff checksums for the same file???