[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Elements/Eprints File Upload Refused
Afternoon all,
Apologies for spamming the list, but I found my solution. The additional 22
"[timestamp]Z.atom" files were deleted via the EPrints interface. As soon
as this was done, I could upload new files to EPrints through Elements.
Thanks for the advice,
James
On Tue, Aug 28, 2018 at 12:14 PM James Kerwin <jkerwin2101 at gmail.com> wrote:
> Hi all,
>
> I've been mulling over this issue over the weekend, and I took another
> look at the Apache error logs this morning immediately after a failed
> upload of the same document through Elements.
>
> It gave me this line:
>
> Can't call method "get_id" on an undefined value at
> /opt/eprints3/perl_lib/Symplectic/RepoProcess/EPrintManager.pm line 335.\n
>
> Going in to the file it would seem as part of the upload of new documents
> to EPrints through Elements, the existing EPrint is copied and the new file
> added to the copy. Line 335 is in the else block of the "clone_to_inbox"
> sub (I know the output from Perl isn't always where the problem actually
> is). I'm leaning towards this being caused by a "$new_eprint" not being
> created on line 333, possibly because not everything in the existing EPrint
> can be copied. Anybody had experience of this?
>
> Thanks,
> James
>
>
> On Fri, Aug 24, 2018 at 12:27 PM James Kerwin <jkerwin2101 at gmail.com>
> wrote:
>
>> Hi John,
>>
>> I attempted to re-upload the actual file just now and it was rejected. I
>> then attempted to re-upload a .txt file name "text.txt." and contained
>> several lines of letters which also didn't work.
>>
>> The people at Symplectic said when they have seen this in the past it has
>> been UTF-8 related, but they didn't think this was the case this time.
>>
>> I could see if I'm able to upload it straight to the repository and not
>> through Elements, although I am a bit reluctant to try that as I don't yet
>> know what the implications might be.
>>
>> Any other guidance you can give would be greatly appreciated.
>>
>> Thanks,
>> James
>>
>> On Fri, Aug 24, 2018 at 11:53 AM John Salter <J.Salter at leeds.ac.uk>
>> wrote:
>>
>>> Hi James,
>>>
>>> The Atom files are part of what Symplectic fires over to Eprints as part
>>> of the deposit process.
>>>
>>> There is config options to keep/not keep them.
>>>
>>>
>>>
>>> My initial hunch (from previous experience) would be that there is a
>>> character in the filename that is causing an issue - possibly an apostrophe.
>>>
>>>
>>>
>>> Do you have a copy of the file being uploaded?
>>>
>>>
>>>
>>> If not, you could try to upload a small (not empty) 'text.txt' file to
>>> the item.
>>>
>>> If this does work , it probably is an issue with the filename of the
>>> real file being uploaded.
>>>
>>> If it doesn't work, then there could be some incorrect XML data being
>>> sent (e.g. non UTF-8), or something else?
>>>
>>>
>>>
>>> Let me know if the above file-based tests work or not - I can direct
>>> more about next steps from there.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>> *From:* eprints-tech-bounces at ecs.soton.ac.uk [mailto:
>>> eprints-tech-bounces at ecs.soton.ac.uk] *On Behalf Of *James Kerwin
>>> *Sent:* 24 August 2018 11:33
>>> *To:* eprints-tech at ecs.soton.ac.uk
>>> *Subject:* Re: [EP-tech] Elements/Eprints File Upload Refused
>>>
>>>
>>>
>>> Thanks for the pointer Alan. I took a look, but nothing jumped out at me.
>>>
>>>
>>>
>>> I have since realised that the issue seems to be related to these two
>>> specific EPrints. Adding files to other pre-existing EPrints works with no
>>> problem. I had taken it at face value from a user that it had suddenly
>>> stopped working.
>>>
>>>
>>>
>>> Suspiciously, there are over 20 Atom XML files, dated May 2017, in each
>>> of the two EPrints along with the pre-existing documents. I suspect these
>>> might be related to the problem.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>
>>>
>>> On Fri, Aug 24, 2018 at 8:34 AM Alan.Stiles <alan.stiles at open.ac.uk>
>>> wrote:
>>>
>>> Hi James,
>>>
>>> I don?t know Elements but it looks from the level 2 and level 3 errors
>>> that the upload is causing EPrints to throw a server error (500) for some
>>> reason. You may find more clues in the EPrints Apache error log?
>>>
>>>
>>>
>>> Alan
>>>
>>>
>>>
>>> *From:* eprints-tech-bounces at ecs.soton.ac.uk [mailto:
>>> eprints-tech-bounces at ecs.soton.ac.uk] *On Behalf Of *James Kerwin
>>> *Sent:* 24 August 2018 07:58
>>> *To:* eprints-tech at ecs.soton.ac.uk
>>> *Subject:* [EP-tech] Elements/Eprints File Upload Refused
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> My repository is EPrints based and accepts file uploads and metadata
>>> from Symplectic Elements.
>>>
>>>
>>>
>>> Recently a colleague was attempting to upload a file through Elements to
>>> an existing EPrint that already contained documents. Unfortunately,
>>> Elements rejected the upload:
>>>
>>>
>>>
>>> "An error occurred whilst uploading the file to the repository. Please
>>> reload the page and try again, or contact your system administrator if the
>>> problem persists."
>>>
>>>
>>>
>>> Other files are still going through from Elements and for each attempted
>>> upload there is a corresponding xml file in the expected area of the
>>> repository server.
>>>
>>>
>>>
>>> I have raised this as a ticket with Symplectic, but was wondering if
>>> anybody else had experienced this and might know what to do?
>>>
>>>
>>>
>>> If anybody could give me some pointers as to how to solve this it would
>>> be brilliant.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>
>>>
>>> Here is an example of the errors shown in Elements System Log (I've
>>> taken some bits out):
>>>
>>>
>>>
>>> The website encountered a problem while handling a webpage request.
>>> Request made to /repositoryupload.html using Mozilla/5.0 (Windows NT 10.0;
>>> Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106
>>> Safari/537.36.
>>>
>>> System component: Website. Level: 5. User: Mr James Kerwin. Elements
>>> Version: 5.8.0.1537. IP: **removed from this email** .
>>>
>>>
>>>
>>> Technical details:
>>>
>>>
>>>
>>>
>>> Exception on machine: NetBIOS name "ELEMENTSAPP01", OS "Microsoft
>>> Windows NT 6.3.9600.0" (64-bit)
>>>
>>> Software instance: Default, Software Version: 5.8.0.1537, Commit Hash: **removed
>>> from this email**
>>>
>>> Command "C:\Windows\SysWOW64\inetsrv\w3wp.exe -ap ".NET v4.5" -v "v4.0"
>>> -l "webengine4.dll" -a
>>> \\.\pipe\iisipmeb559885-1967-4a5e-84df-428b9ab8d631 -h
>>> "C:\inetpub\temp\apppools\.NET v4.5\.NET v4.5.config" -w "" -m 0" (32-bit)
>>>
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> Log entry ID: **removed from this email**
>>>
>>> Logged at: 17:16:36 17/08/18
>>>
>>> Level 1:
>>>
>>> -------
>>>
>>> Exception type:
>>> Symplectic.Elements.DataEntities.WebsiteServerErrorException
>>>
>>> Message: The website encountered a problem while handling a webpage
>>> request.
>>>
>>> Exception not yet thrown.
>>>
>>>
>>>
>>> Level 2:
>>>
>>> -------
>>>
>>> Exception type: Symplectic.Elements.Repository.Client.RepositoryException
>>>
>>> Message: Response status code does not indicate success: 500 (Internal
>>> Server Error).
>>>
>>> Stack trace:
>>>
>>> at
>>> Symplectic.Elements.Repository.Client.Rt1RepositoryClient.UploadFile(ApiRepositoryPublication,
>>> Rt1RepositoryFileType, MonitoringStreamCopier, String, String, String,
>>> Int32)at
>>> Symplectic.Elements.Repository.Client.Rt1RepositoryClient.UploadContentFile(ApiRepositoryPublication,
>>> FileToDeposit)at
>>> Symplectic.Elements.Website.Application.Handlers.Rt1DepositActionPage.UploadFile()at
>>> Symplectic.Elements.Website.Application.Handlers.Rt1DepositActionPage.ProcessRequest(String)at
>>> Symplectic.Elements.Website.Application.BaseHandlers.SessionlessBufferlessHandler.ProcessRequest(HttpContext)
>>>
>>> Level 3:
>>>
>>> -------
>>>
>>> Exception type: System.Net.Http.HttpRequestException
>>>
>>> Message: Response status code does not indicate success: 500 (Internal
>>> Server Error).
>>>
>>> Stack trace:
>>>
>>> at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()at
>>> Symplectic.Elements.Repository.Client.Rt1RepositoryClient.UploadFile(ApiRepositoryPublication,
>>> Rt1RepositoryFileType, MonitoringStreamCopier, String, String, String,
>>> Int32)
>>>
>>>
>>>
>>> -- The Open University is incorporated by Royal Charter (RC 000391), an
>>> exempt charity in England & Wales and a charity registered in Scotland (SC
>>> 038302). The Open University is authorised and regulated by the Financial
>>> Conduct Authority in relation to its secondary activity of credit broking.
>>>
>>> *** Options:
>>> http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>>> *** Archive: http://www.eprints.org/tech.php/
>>> *** EPrints community wiki: http://wiki.eprints.org/
>>> *** EPrints developers Forum: http://forum.eprints.org/
>>>
>>> *** Options:
>>> http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>>> *** Archive: http://www.eprints.org/tech.php/
>>> *** EPrints community wiki: http://wiki.eprints.org/
>>> *** EPrints developers Forum: http://forum.eprints.org/
>>>
>> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
>> *** Archive: http://www.eprints.org/tech.php/
>> *** EPrints community wiki: http://wiki.eprints.org/
>> *** EPrints developers Forum: http://forum.eprints.org/
>>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20180828/69c9e2e8/attachment-0001.html