• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

Concurrency: Target uploaded file already exists, aborting operation

Status
Not open for further replies.
H

hlx98007

Chevereto Member
▶🚶‍Reproduction steps
  1. Download 3.12.1 version and setup a Google Bucket correctly (using the old way)
  2. Upload some image (i.e. daylight_1.jpg) and produce an error, internal server error
  3. Upgrade Chevereto to 3.12.2 with the GCS fix.
  4. Fix GCS service account private key section to JSON format
  5. Upload the same image again (daylight_1.jpg)
😢Unexpected result

Concurrency: Target uploaded file already exists, aborting operation

📃Error log message

2018/11/08 20:23:38 [error] 6793#0: *28499 FastCGI sent in stderr: "PHP message: Concurrency: Target uploaded file already exists, aborting operation" while reading response header from upstream, client:


I have an idea that file was not properly cleaned up somewhere, but I have no idea where to find the file in the cache/temp system?
 
The concurrency error is triggered when the temp file is still there shortly after previously upload the alleged image.

The file (temp) should be deleted immediately after successfully uploading, but some file systems are heavyly cached, way beyond the realm of usable.

I will try to improve the detection, but if the fs is too slow there's very little left to optimize here.
 
Ok, did some research and I discovered a different bug 😂. But hey, good news is that turns out that it could help to fix this issue.

Problem is, that the Storage::getStorageValidFilename is not working at all and it is not getting unique names from the database, a silly bug on my end there. Can't point out since when this is going on, easily, years.

deja_q_hd_046_resized_6484.jpg

Anyway, the patch will be released in the next revision 💪
 
Status
Not open for further replies.
Back
Top