Duplicate ID bug ??

[Oakley]

Did this duplicate ID bug get fixed earlier last year:

https://chevereto.com/community/threads/chevereto-v3-9-0.8399/page-2#post-46155

Just had it earlier today with 3.10.5

Database has concurrent duplicate entries for the same image_name hmmm... thats not right.

One file I uploaded, the other a member. Using ID as file naming method.

Only had this once and I will keep an eye on it.

Out of interest how did people get round it ? I'm reluctant to delete the files in case it corrupts something. Presumably the db entries are hashed (?) so I'm thinking it's imposible to correct directly in the database ?

 

[Rodolfo]

ID based filename works directly with the image table. The system inserts a dummy row, gets its ID and uses that ID for the inserted image. It is impossible to get a collision there unless your database server isn't working properly.

 

[Oakley]

This is a shot of the table showing the duplicate image_name

I'll take a look at mysql to see if anything is amiss but it's a pretty standard setup. Images were small and there's heaps of ram on the server (7GB free).

 

[Rodolfo]

I'm sorry but I won't be able to help you at all. Is not that there's something to debug.

 

[Rodolfo]

What DB driver are you using? I changed the ID reservation system but it reads this from http://php.net/manual/en/pdo.lastinsertid.php

This method may not return a meaningful or consistent result across different PDO drivers, because the underlying database may not even support the notion of auto-increment fields or sequences.

Like I said, I do an insert+delete then I use lastInsertId.

app/lib/classes/class.image.php

                    $query = 'INSERT INTO
                    `' . DB::getTable('images') . '` (`image_' . ltrim(implode('`,`image_', array_keys($dummy)), '`,`') . '`)
                    VALUES (:image_' . str_replace(':', ',:', implode(':image_', array_keys($dummy))) . '); DELETE FROM `' . DB::getTable('images') . '` WHERE image_id = LAST_INSERT_ID();';
                    $db = DB::getInstance();
                    $db->query($query);
                    foreach ($dummy as $k => $v) {
                        $db->bind(':image_' . $k, $v);
                    }
                    $db->exec();
                    $target_id = $db->lastInsertId();

Maybe lastInsertId is won't work properly 100% of the time? Maybe this code should be used instead:

                    $dummy_insert = DB::insert('images', $dummy);
                    DB::delete('images', ['id' => $dummy_insert]);
                    $target_id = $dummy_insert;

There should be NO WAY in which the function should fail. It is getting the ID directly so it shouldn't fail unless your DB is not configured properly and it doesn't handle client isolation properly.

 

[Oakley]

It's a normal mysqli setup and I agree it should not fail, each connection should be isolated. Not a problem, it seems to be a one off, I'll just keep an eye on it, cheers 😉

 

[Oakley]

I've only just realised that this was mentioned here back in Dec and class.image.php was updated in 3.10.6 . From what I can see this is the same issue. Not sure if you realised that I was taking about 3.10.5 ?

Anyway, I'm not ready yet to upgrade to 3.10.6 completely, but in the meantime would it be fine to merely update class.image.php (I assume it would be)?

 

[Rodolfo]

3.10.5 is not patched and it has that issue. Prior 3.10.6 I used a file lock system but that didn't work as expected (some users reported collisions) and even being impossible for me to replicate, I opted to change how it works to make impossible to get a collision there.

You should upgrade to 3.10.6