[5.0.8] Downloads creates a Topic with broken screenshot/image IF downloads and forums use different storage configurations (should use copy() not duplicate()

Hello,

This is the sort of bug that you will never see if you only test on V5... The bug shows up because our system has been running for years (at least 2007) and has been upgraded from previous versions to V5. I'm not sure how you could create the bug on a V5 only system other than using backdoor techniques. In order to investigate the bug on our V5 test system I had to create an additional storage configuration record ('core_file_storage') and then delete the storageConfigurations record from core_store so that it got recreated from the configuration records.

For unknown reasons (before I became involved in 2016) nearly all file storage items were set to the default of /uploads - but, 'downloads screenshots' were set to the different configuration of /screenshots. As far as I know this used to work on V4 as we got no reports of problems (and I can no longer go back to V4 to test).

Under V5 when the downloads topic is created (cbitoptions_topic_screenshot set on) the resulting screenshot in the topic is a broken link so the image file does not display. The issue is that the link in the topic refers to /uploads (correct for a topic) but the image file is actually in /screenshots (which was correct for the original downloads screenshot).

I believe that the error is the following... [5.0.8] line 2757 in applications/downloads/sources/File/File.php does a duplicate() when it should be a copy(<newstoragelocation>).

The problem being that duplicate() keeps the original storage configuration (i.e./screenshots) whereas we want a file in the target location (i.e. /uploads for the forum). Having duplicated the file in /screenshots line 2763 resets the location_key to foums -- which expects the file to be in /uploads.

I'm just reporting the bug here. As I said, I don't know how this bug would ever show up on a new V5 system as we cannot create new storage configurations. It was easy under V4 to create lots of storage configurations in different directories so I expect this sort of bug to only show up on systems that have been upgraded from V4 or earlier.

Anyway, my proposed workaround is to reset 'downloads screenshots' to use the 'uploads' storage configuration so all storage will be consistent on our system...

Thanks very much.

John