Dear Dspace-tech, We are running dspace v5.1, xmlui.
When using the command line batch importer, I'm experiencing some strange behavior in where dspace looks for the location of my SAF zip file. > [user@hostname]$ /apps/mdsoar/bin/dspace import -t -a -e u...@notreal.edu -s > /path/to/file/ -z saf.zip -c 11603-STAGE/363 -m mapfile > **Test Run** - not actually importing items. > Destination collections: > Owning Collection: Test Collection > java.io.FileNotFoundException: /path/to/file/path/to/file/saf.zip (No such > file or directory) > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.<init>(ZipFile.java:215) > at java.util.zip.ZipFile.<init>(ZipFile.java:145) > at java.util.zip.ZipFile.<init>(ZipFile.java:159) > at org.dspace.app.itemimport.ItemImport.unzip(ItemImport.java:2021) > at org.dspace.app.itemimport.ItemImport.unzip(ItemImport.java:1987) > at org.dspace.app.itemimport.ItemImport.unzip(ItemImport.java:2098) > at org.dspace.app.itemimport.ItemImport.main(ItemImport.java:490) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:225) > at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:77) > java.io.FileNotFoundException:/path/to/file/path/to/file/saf.zip (No such > file or directory) > Deleting temporary zip directory: /apps/myapp/imports > ***End of Test Run*** > Started: 1438117375828 > Ended: 1438117376345 > Elapsed time: 0 secs (517 msecs) This is a new process for us, so it is entirely possible that I am invoking this command incorrectly, but my understanding is that the -s flag is used to declare the directory where your batch folder is located, and the -z flag is where you specify the name of the .zip file. As the above (slightly sanitized) stack trace shows, however, the importer looks for the batch file in a non-existant location constructed by duplicating the specified path twice over. Thus, I specified "/path/to/file" and dspace looks in "/path/to/file/path/to/file". This pattern holds no matter what directory I attempt to load from. The only way I have been able to get it to work so far is by invoking the import command from the directory where the zip is located, and specifying "-s ." for the path. Any advice would be appreciated. Josh Westgard University of Maryland Libraries ------------------------------------------------------------------------------ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
