Hi Hayden, Richard
I was in the same situation you are in a few weeks ago, although I was trying
what you are trying to do using the python client.
Here is how I solved the problem:
- create an atom entry (which works for you), with the header in_progress = True
- add the file by posting to the "edit_media" url that I get in the deposit
receipt from the previous entry creation. To do this, these are the headers I
send:
filename="myfile.xxx" (this will get the name right in DSpace)
mimetype="application/zip"
packaging="http://purl.org/net/sword/package/Binary"; (this will force the use
of the Binary ingester, which is detecting the MIME type automatically).
I also slightly modified the BinaryIngester in DSpace because there was a small
bug (which I reported). With these headers, and with "my" BinaryIngester, the
file type is stored correctly. The only thing missing is the file's Description.
I created a simple command line tool to send files to DSpace, you can find it
here: Project: SWORD Uploader
If you need the modified BinaryIngester, I can send you the compiled file (or
the source if you prefer), if this could solve your problem.
Another way of depositing many files is to use the SimpleZip ingester: just zip
all the files and post them with
packaging="http://purl.org/net/sword/package/SimpleZip"; . This will create an
entry with a title defined by the name of the zip file. If you send the header
in-progess=True, the entry will remain open. You can then update the metadata
using the appropriate command.
Richard:
>As long as the mime type is in the "accept" list, then you should be
>able to use the correct mime type in the deposit (you could also set
>your accepts config option to */*.
I tried using */* but it didn't work for me, only specific MIME types worked.
Hope this help,
cheers
Marco
--------------------------------------------------
Marco Fabiani
Postdoctoral Research Assistant
Centre for Digital Music
School of Electronic Engineering and Computer Science
Queen Mary, University of London
Mile End Road, London E1 4NS, UK
On 30 Apr 2012, at 13:55, Hayden Young wrote:
> Hi Marco and Richard
>
> Closer still to a solution I think.
>
> Richard, I commented out the offending ingester:
>
> org.dspace.swordpackagers.SwordXifIngester = image/jpeg
>
> unfortunately, this did not solve the problem but I now get the same error as
> if I attempt to ingest a PDF (I.e. file not found) so at least now there is
> some consistency. I checked all permissions on my upload.tempdir; as
> bitstreams are being successfully associated with items if I set the mimetype
> to "application/zip" I am guessing my directory permissions are correct?
>
> Marco, thanks for the suggestion. I did set the mime type as application/zip
> and had some success with uploading the bitstreams; that is, the bitstream is
> appearing within the item). There are two issues:
>
> 1. The file type is not detected and so it is given the file type "Unknown"
>
> 2. No matter which type of file or how many files are uploaded, the first
> letter is always dropped from the file name. So, for example my_image.jpg
> will be renamed y_image.jpg or my_document.pdf will be y_document.pdf. I
> checked my mimetype settings and both image/jpeg and application/pdf are
> registered.
>
> Therefore, I'm thinking could this be a swordv2 config issue? I have attached
> in case it assists with diagnosis.
>
> Cheers
>
>
> Hayden
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
