End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
Thanks!
Sherry Lake
Yes, the Bag should be something you can unzip and inspect. If you haven’t set up the ArchiverClassName and related settings, it’s possible that the problem is misconfiguration.
If not, a problem with the Bag might indicate that some metadata and/or file problem exists – hopefully documented in the server log.
W.r.t. configuration, there are currently 3 options for where Bags should be sent when created
- to DSpace as the front end of Duracloud/Chronopolis (and DPN before it folded)
- to the Google cloud
- to a local file directory (which, as planned by Odum, could be synced with iRoDS for archival purposes).
The BagIt Export section (https://guides.dataverse.org/en/5.4/installation/config.html?highlight=archiverclassname#id104) has examples of the setup for all three.
All three share the same code for generating the Bag and it is streamed to the final destination wherever that may be. Network interruptions during the Bag transfer could result in an incomplete Bag. Since the Bag code is retrieving an zipping all of the files in the dataset as well, if any of those are missing/there are network access problems reading them, the Bag could also be incomplete. There is some functionality to retry connections in the code so truly intermittent problems shouldn’t be an issue but if a file just isn’t accessible, Bag creation would probably fail.
-- Jim
--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dataverse-commu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dataverse-community/9e99b9ec-f30b-46c1-8efc-aff8320fa7f5n%40googlegroups.com.
Ah – sorry. The short version is a typo. The long edu.harvard.iq.dataverse.engine.command.impl.LocalSubmitToArchiveCommand is the full name and package hierarchy for the class that’s being used. (All of the Dataverse code is in the edu.harvard.iq.dataverse package or some sub-package from there.).
If you can make an issue about the typo, that would be helpful (PR as well if you’re up for that).
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/e7b0fea0-b892-4168-969e-e5cce4e76e30n%40googlegroups.com.
":ArchiverClassName":"edu.harvard.iq.dataverse.engine.command.impl.LocalSubmitToArchiveCommand"
":BagItLocalPath":"/home/xw5d/BagItStorage/"
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/MN2PR07MB73431F69F32D5ACC1A730978BFF19%40MN2PR07MB7343.namprd07.prod.outlook.com.
This is pretty clearly something about the certificate – hard to know without being able to see it. In general, the Bag generator code is being pretty lenient about checking the certificate (since they are all for files that should be on your server anyway), but there must be something about it that Java doesn’t like. If this is a locally signed certificate just used for dev, it may be that the certificate isn’t in the Java keystore. It’s also possible that there’s something like the certificate not listing the dvdev.lib.viriginia.edu name as the server it is for, etc.
In any case, I think this is probably something that you can resolve locally, i.e. by adding your cert to the local java keystore on your machine (lots of web resources on how to do that). If not, or if that’s not clear, let me know and we might be able to do a quick screen share so I can see the cert/help debug.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/CADL9p-Xs3bcfss-K2-NV%3De6ze5a86fq6c8xjrZ_d2tNR5q%3D-DA%40mail.gmail.com.