Replace file broken in latest builds?

[Stephen S]

Not sure when this occurred, but it seems that replacing a file in the latest svn version(s) is broken. You get the upload dialog, and seemingly can upload a file, and the image is not replaced. (there is also a small warning triangle next to any image one tries to upload, but no information is given in the log).

[Stephen S]

I turned on debugging, but that does not shed any more light on this (but perhaps I am missing something in the debug file, there is nothing marked ERROR anywhere). To compare what was happening between a replace file (which fails) and a new upload (which succeeds) I did both (in that order). But the debug logs for both look much the same (yet the first one failed and the second one succeeded). Here are lines that had any part of my filename in them from the debug:

2016-08-25 11:30:35 PLUPLOAD - receiving file from user admin,  filename RS49_IMG_3246-lpr.JPG, chunk 0 of 1

2016-08-25 11:30:35 PLUPLOAD - handling non-multipart upload file received from user admin,  filename RS49_IMG_3246_lpr.JPG, chunk 1 of 1

2016-08-25 11:30:35 PLUPLOAD - adding data from /tmp/phppNDVGf to /var/www/resourcespace/include/../filestore/tmp/plupload/67e1a39955e2c8b07b4a34c3c022e319/RS49_IMG_3246_lpr.JPG.part. file received from user admin,  filename RS49_IMG_3246_lpr.JPG, chunk 1 of 1

2016-08-25 11:30:35 PLUPLOAD - adding data from /tmp/phppNDVGf to /var/www/resourcespace/include/../filestore/tmp/plupload/67e1a39955e2c8b07b4a34c3c022e319/RS49_IMG_3246_lpr.JPG.part. file received from user admin,  filename RS49_IMG_3246_lpr.JPG, chunk 1 of 1

2016-08-25 11:30:35 PLUPLOAD - processing completed upload of file received from user admin,  filename RS49_IMG_3246_lpr.JPG, chunk 1 of 1

2016-08-25 11:35:36 PLUPLOAD - receiving file from user admin,  filename RS49_IMG_3246-lpr.JPG, chunk 0 of 1

2016-08-25 11:35:36 PLUPLOAD - handling non-multipart upload file received from user admin,  filename RS49_IMG_3246_lpr_1.JPG, chunk 1 of 1

2016-08-25 11:35:36 PLUPLOAD - adding data from /tmp/phpLgka0u to /var/www/resourcespace/include/../filestore/tmp/plupload/67e1a39955e2c8b07b4a34c3c022e319/RS49_IMG_3246_lpr_1.JPG.part. file received from user admin,  filename RS49_IMG_3246_lpr_1.JPG, chunk 1 of 1

2016-08-25 11:35:36 PLUPLOAD - adding data from /tmp/phpLgka0u to /var/www/resourcespace/include/../filestore/tmp/plupload/67e1a39955e2c8b07b4a34c3c022e319/RS49_IMG_3246_lpr_1.JPG.part. file received from user admin,  filename RS49_IMG_3246_lpr_1.JPG, chunk 1 of 1

2016-08-25 11:35:36 PLUPLOAD - processing completed upload of file received from user admin,  filename RS49_IMG_3246_lpr_1.JPG, chunk 1 of 1

2016-08-25 11:35:37 adding 3246

2016-08-25 11:35:37 resolving keyword 3246. Create=true

2016-08-25 11:35:37 resolving normalized keyword 3246.

2016-08-25 11:35:37 SQL: select ref value from keyword where keyword='3246'

2016-08-25 11:35:37 SQL: insert into resource_data(resource,resource_type_field,value) values ('50','51','RS49_IMG_3246-lpr.JPG')

Does anyone have a clue as to why this is failing? Or where to turn on some sort of error logging? It seems like the debug log shows every command, but not whether it succeeded or failed.

[Stephen S]

Well, for anyone who cares the bug was introduced somewhere in image_processing.php and (possibly) upload_plupload.php with revision 8661. Reverting just those two files (to 8659) fixes the replace file problem AND the meta data problem I reported elsewhere.

[Stephen S]

I was wrong, this only fixes the replace file problem. The writing meta data to downloads problem reported elsewhere still exists.

[Stephen S]

This seems fixed as of svn 8718