• 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

Image swapped with another user image, mismatch

Status
Not open for further replies.

lovedigit

👽 Chevereto Freak
This happened twice this week. I don't know how I can guide you to recreate this bug, but it definitely happened to me earlier last year. It is not frequent but random.

I was uploading an image and my medium image and the original image doesn't match on one of my images. It appears when two people upload an image at exactly the same time, the image gets mismatched. The image also gets stretched to the resolution of the image uploaded by another user. It is too confusing to even comprehend in words. lol

Have a look at this image uploaded by a guest user.
https://lensdump.com/i/sl85Z

Origianl size: https://i.lensdump.com/i/sljci.jpg

Medium Size: https://i.lensdump.com/i/sljci.md.jpg

Unfortunately, I have deleted my image, otherwise, I could have shared that as well. My image had exact same original size image as medium size image uploaded by the guest user, and my medium size image was exactly as the image original size image uploaded by the guest.

so:

My original size image = guest's medium size image

My Medium size image = guest's original size image.

Please have a look. There might be more such cases experienced by other users. Luckily I could find this bug as that user reported it to us. Coincidently, I found out his image was mismatched with mine when I noticed that his original is same as my medium.

Another example:

This image was uploaded by me. But it isn't what I uploaded.
https://lensdump.com/i/sl2nK

Original image: https://i.lensdump.com/i/sliOm.jpg

Medium image: https://i.lensdump.com/i/sliOm.jpg


It is the image uploaded by another user. See his image.
https://lensdump.com/i/sl1VC

As you may have noticed, my image is shown as his, but instead of being the same resolution as the other user's image. His image is shown stretched to my image's original resolution.

Update: After clearing the browser cache, the medium and original image is no longer shown as different. Instead, both images are same. However, we got our images completely swapped.

How is this even possible?

I have his other user's image, and another user has mine. As stated earlier, it is not something which happened frequently. It is rare, but it shouldn't ever happen. This is a violation of privacy if a user wants to keep his image private and it ends up in random user's account.
 
Last edited:
It is not just the id mismatch. There is same image at both ID. Possible explanation is we both uploaded an image at exactly the same time. I usually upload images in bulk. Usually, 100-500 in range.

There are chances that other user might be uploading an image while my images are processed in queue.

I checked and downloaded the image from the server and it appears to be exactly the same image at the both ID.
 
I've detected a collision in the ID reservation system.

upload_2017-12-14_15-37-54.png

Lines 747-753 define a loop which goal is to get a valid ID candidate for every upload process. Unfortunately, since the DB is slower than the disk there is a potential concurrency issue in L740.

Basically, the system checks the DB for the AUTO_INCREMENT value and from there, it generates locks (files) until it gets a valid ID candidate. When several peers are using the system, multiple overlaps could happen and N process could happen at the same time and lock (reserve) the same ID.

This is all because I'm using the filesystem on top of the DB to dummy the reserved ID in the table. The only way to get rid of this collision is to do all the ID reservation thing at DB.

I already have a workaround that I'm testing locally and eventually, I will try it on the demo. The new system simply insert a dummy row and delete it. By doing this on the same statement I'm making sure that the ID being handled properly.
 
Here's the patch. It should get rid of this kind of issues. It does a cheap trick (inserts a dummy row then removes it) which allows reserving an ID without any collision because it does it directly in the database and relies on per-client functions.

Give it a try and let me know how it goes.
 

Attachments

Status
Not open for further replies.
Back
Top