upload_large is changing the extension, making uploads fail

[DiscoJustice]

When uploading raw files using upload_large, the SDK seems to be adding characters to the end of the extension, making the files be rjected because they don't match the allowed_formats value. On my windows machine, it adds .tmp, and on our Ubuntu servers it's adding 5 random characters. This difference might be due to the way the OSs handle temp files.

Here's my code:

<?php
use \Cloudinary\Uploader;

require("./src/Cloudinary.php");
require("./src/Uploader.php");

\Cloudinary::config(array(
    'cloud_name'    => 'XXX',
    'api_key'       => 'XXX',
    'api_secret'    => 'XXX'
));

$filename = "a test document.txt";
$options['return_error']        = true;
$options['resource_type']       = 'auto';
$options['public_id']           = $filename;
$options['allowed_formats']     = array('txt');

$uploadedFileData = Uploader::upload_large($filename, $options);

print_r($uploadedFileData);

This yields the result:

Array
(
    [error] => Array
        (
            [message] => Raw file format tmp not allowed
            [http_code] => 400
        )

)

If I remove allowed_formats then the upload works, but note the public_id, url, secure_url have .tmp on the end, and the original filename is wrong.

Array
(
    [public_id] => a test document.txt.tmp
    [version] => 1530109839
    [signature] => a4880c7ff86ab0fb5e9e3d6ba4396e42d207be01
    [resource_type] => raw
    [created_at] => 2018-06-27T14:30:39Z
    [tags] => Array
        (
        )

    [bytes] => 17
    [type] => upload
    [etag] => b3a809c63dee723a35b2be625a77a4e0
    [placeholder] =>
    [url] => http://res.cloudinary.com/crowdicity-eu-cld/raw/upload/v1530109839/a%20test%20document.txt.tmp
    [secure_url] => https://res.cloudinary.com/crowdicity-eu-cld/raw/upload/v1530109839/a%20test%20document.txt.tmp
    [overwritten] => 1
    [original_filename] => cld246C
)

[marissa-masangcay]

Hi,

When you upload the file in your Windows system do you by chance have the file still open? Windows has the behavior of creating temporary files when the file is currently open and potentially being edited. The temp files are closed and deleted once Word is shut down. If you do have it open can you try closing the file and then try uploading? Here is some documentation on the behavior: https://support.microsoft.com/en-us/help/211632/description-of-how-word-creates-temporary-files

Also are you able to upload raw files with our upload method (rather than upload_large) without the tmp extension being added?

Regarding Ubuntu appending random characters at the end, we do this by default to ensure a unique filename. However if you'd like to turn this behavior off you can include the parameter unique_filename = false upon the upload call and this should stop the random characters from being added but please keep in mind this will overwrite an existing file if they have the same public ID. If you'd like to read more about this you can do so in this article: https://support.cloudinary.com/hc/en-us/articles/202520762-How-to-upload-images-while-keeping-their-original-filenames-

Hope this helps!

[DiscoJustice]

Thanks for your reply - I definitely don't have the file open - however upload_large itself does create a temporary copy of the file in the system's temp folder https://github.com/cloudinary/cloudinary_php/blob/46546ac08d121ae1a4fee8fde46d386998927326/src/Uploader.php#L101

Regarding the random characters, my first thought was that Cloudinary was doing this - however, if that's the case, then Cloudinary is adding the random characters directly to the extension, and then complaining that the extension is not on the whitelist. For example, when I run this script on our Ubuntu server, the error looks like this:

Array
(
    [error] => Array
        (
            [message] => Raw file format txtf5hg9 not allowed
            [http_code] => 400
        )

)

Note that the first 3 letters are indeed the extension of the file I provided (a text file), but the last 5 aren't mine. It seems unlikely Cloudinary would add those extra characters before the file has even uploaded, and then reject the file because of the characters it added. So I think this might be coming from the operating system giving the temp file a unique name, in the same way I see the .tmp extension on Windows. I can't think of how else the filename would be getting changed. And while that wouldn't directly be the fault of the SDK, it should take that into account, or uploads just stop working.

I'm not able to check right now, but yes, I believe the regular upload works.

[marissa-masangcay]

Hi,

I did some testing and it does look like the upload method works in case that is a suitable workaround in the meantime. I will be filing this as a bug and will update you once we have made the necessary changes. Thank you for bringing this to our attention.

[GerberaLee]

Want to konw,the question is resolve or not ?

[marissa-masangcay]

Hi @GerberaLee, I apologize for the delayed update but this has been resolved.