Weird thing after upgrade to 3.2.1.1 from 3.1.4.
Upgrade script showed no errors in library files schema.
Every file existing in DB registered under library_files now produces a blank page after click from both front and back.
.
Trigger url seem ok : https://domain.com/$$$call$$$/api/file/file-api/download-library-file?libraryFileId=187
File is present in the catalogue context and has suitable permissions.
DB debug presents right syntax =
file_id, context_id, file_name, original_file_name, file_type, file_size, type, date_uploaded, submission_id, public_access FROM library_files WHERE file_id = 93 AND context_id = 32 \x$
PKP-Database-Logger 1601033791.1887: \n(mysqli): SELECT * FROM library_file_settings WHERE file_id = ‘93’ \xc2\xa0 \n\n,
Queried record is actually present in DB
Ojs debug shows nothing but blank page
Browser debug shows code 200 but bad file size.
Initiator - /lib/pkp/js/classes/linkAction/PostAndRedirectRequest.js?v=3.2.1.1
Newly added files does not show any above symptoms.
We had that too. The temporary solution was to rename the files in the {files_directory}/contexts/{journalid}/library/filexy.pdf to filexy-OTH.pdf if it was uploaded to the “Other” section of the publisher library.
However, we already have a complaint by a publisher that the filenames should remain untouched.
@asmecher : Don’t know, why this change had been introduced - we and the publishers are unhappy with that.
Hi all,
This is likely related to Submitting file to Submission Library overwrites Publisher Library files · Issue #5471 · pkp/pkp-lib · GitHub – see the description there for more information. It should copy files to the new expected location (doing automatically what you describe doing manually, @mpbraendle), but if the upgrade script is not permitted due to file permissions, you should have seen warnings during upgrade. Did you see anything like that?
Regards,
Alec Smecher
Public Knowledge Project Team
Yes @asmecher - this was exactly the case. I fixed the permissions and ran the upgrade script a seccond time, but then it did not copy the files. That’s why I did then manually.
Hi @mpbraendle,
Ah, that explains it. Running the upgrade script a second time won’t re-run the same tasks that had run earlier – after a successful upgrade (warnings aside) the version number in the database will be updated, and after that OJS won’t run upgrade stages from previous versions.
Regards,
Alec Smecher
Public Knowledge Project Team
Fortunately, I kept the log of the first run.
1 Like
