same avatars for everyone after upgrade to v1.1.0 #488

Closed
opened 2025-11-02 03:25:17 -06:00 by GiteaMirror · 12 comments
Owner

Originally created by @ghost on GitHub (Mar 12, 2017).

  • Gitea version (or commit ref): v1.1.0 (updated from v1.0.2)
  • Git version: 2.1.4
  • Operating system: Debian 8 (stable)
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
    • Not really possible
  • Log gist: n/a

Description

After replacing my v1.0.2 gitea binary with a new v1.1.0 one and starting gitea, all avatars are the same (it was an avatar of a group). All images itself are still in the avatars folder on disk but gitea only shows one for all accounts (user/groups). I cleared my cache but I had to upload all avatars again to get them connected to all user accounts and groups.

Originally created by @ghost on GitHub (Mar 12, 2017). - Gitea version (or commit ref): v1.1.0 (updated from v1.0.2) - Git version: 2.1.4 - Operating system: Debian 8 (stable) - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - [x] Not really possible - Log gist: n/a ## Description After replacing my v1.0.2 gitea binary with a new v1.1.0 one and starting gitea, all avatars are the same (it was an avatar of a group). All images itself are still in the `avatars` folder on disk but gitea only shows one for all accounts (user/groups). I cleared my cache but I had to upload all avatars again to get them connected to all user accounts and groups.
GiteaMirror added the backport/doneissue/criticaltype/bug labels 2025-11-02 03:25:17 -06:00
Author
Owner

@ptman commented on GitHub (Mar 13, 2017):

Some of the larger avatar changes was in 80f900ebae

@ptman commented on GitHub (Mar 13, 2017): Some of the larger avatar changes was in https://github.com/go-gitea/gitea/commit/80f900ebae5c52f736f667a81bbc1ab815344efc
Author
Owner

@ghost commented on GitHub (Mar 13, 2017):

@ptman This might be the reason but for larger installations this bug can be really annoying, especially if you use avatars to distinguish commits and accounts.

@ghost commented on GitHub (Mar 13, 2017): @ptman This might be the reason but for larger installations this bug can be really annoying, especially if you use avatars to distinguish commits and accounts.
Author
Owner

@mjwwit commented on GitHub (Mar 13, 2017):

The issue is most likely in the migration script which translates the old user-id based avatar filenames to md5 based filenames and updates the DB accordingly. All the filenames are correctly updated, but the database will no longer reference the correct avatar after migrating.

Make sure you keep your db backup from before the migration, as fixing the user avatars without this backup will require manual work!

@mjwwit commented on GitHub (Mar 13, 2017): The issue is most likely in the migration script which translates the old user-id based avatar filenames to md5 based filenames and updates the DB accordingly. All the filenames are correctly updated, but the database will no longer reference the correct avatar after migrating. Make sure you keep your db backup from before the migration, as fixing the user avatars without this backup will require manual work!
Author
Owner

@ghost commented on GitHub (Mar 13, 2017):

@mjwwit Well, it is a private instance with 3 accounts so I updated everything manually. Nevertheless one should fix the update script.

@ghost commented on GitHub (Mar 13, 2017): @mjwwit Well, it is a private instance with 3 accounts so I updated everything manually. Nevertheless one should fix the update script.
Author
Owner

@eryx commented on GitHub (Mar 15, 2017):

got the same bug in my updating, can only rollback to v1.0.2.
hope to add the bugfix in v1.1.1

@eryx commented on GitHub (Mar 15, 2017): got the same bug in my updating, can only rollback to v1.0.2. hope to add the bugfix in v1.1.1
Author
Owner

@WolfgangKluge commented on GitHub (Apr 17, 2017):

@mjwwit since in the database, I can see the last migrated md5 on all users, I think it's here 74cde12677/models/migrations/v20.go (L61)

@WolfgangKluge commented on GitHub (Apr 17, 2017): @mjwwit since in the database, I can see the last migrated md5 on all users, I think it's here https://github.com/go-gitea/gitea/blob/74cde12677bc548487ed1caf192eb19b0b7cf99c/models/migrations/v20.go#L61
Author
Owner

@richmahn commented on GitHub (May 7, 2017):

I'm getting this as well. All my custom avatars (I have 2890 users, many which have custom avatars uploaded) be the same avatar! I added a few Printfs to the Migration v20.go file, migrating up from v15, and I see this:

USER TO UPDATE: 4613, {f295aae8bd4b6dca44ad1c35bcf99ad7 true}
2017/05/07 11:07:51 [I] [SQL] UPDATE `user` SET `avatar` = ?  [f295aae8bd4b6dca44ad1c35bcf99ad7]

As you can see, there is no WHERE condition to set avatar where id = 4613!

@richmahn commented on GitHub (May 7, 2017): I'm getting this as well. All my custom avatars (I have 2890 users, many which have custom avatars uploaded) be the same avatar! I added a few Printfs to the Migration v20.go file, migrating up from v15, and I see this: ``` USER TO UPDATE: 4613, {f295aae8bd4b6dca44ad1c35bcf99ad7 true} 2017/05/07 11:07:51 [I] [SQL] UPDATE `user` SET `avatar` = ? [f295aae8bd4b6dca44ad1c35bcf99ad7] ``` As you can see, there is no WHERE condition to set `avatar` where id = 4613!
Author
Owner

@richmahn commented on GitHub (May 7, 2017):

@WolfgangKluge You got the wrong line number there that is causing this, as the UPDATE call wasn't done right, apparently. 74cde12677/models/migrations/v20.go (L66)

As I wrote above, setting the ID to userID doesn't cause it to render a "WHERE id = ?"

@richmahn commented on GitHub (May 7, 2017): @WolfgangKluge You got the wrong line number there that is causing this, as the UPDATE call wasn't done right, apparently. https://github.com/go-gitea/gitea/blob/74cde12677bc548487ed1caf192eb19b0b7cf99c/models/migrations/v20.go#L66 As I wrote above, setting the ID to userID doesn't cause it to render a "WHERE id = ?"
Author
Owner

@richmahn commented on GitHub (May 7, 2017):

Is this "WHERE" being excluded only happening for MySQL?

Never mind, verified this was doing it in Postgresql too.

@richmahn commented on GitHub (May 7, 2017): Is this "WHERE" being excluded only happening for MySQL? Never mind, verified this was doing it in Postgresql too.
Author
Owner

@WolfgangKluge commented on GitHub (May 10, 2017):

@richmahn I thought of this common mistake: https://github.com/golang/go/wiki/CommonMistakes#using-goroutines-on-loop-iterator-variables

The line I mentioned is only the first of a sequence..

@WolfgangKluge commented on GitHub (May 10, 2017): @richmahn I thought of this common mistake: https://github.com/golang/go/wiki/CommonMistakes#using-goroutines-on-loop-iterator-variables The line I mentioned is only the first of a sequence..
Author
Owner

@lunny commented on GitHub (May 16, 2017):

@richmahn I think you are right. I have sent #1724 and #1729 to fix this and both are merged.

@lunny commented on GitHub (May 16, 2017): @richmahn I think you are right. I have sent #1724 and #1729 to fix this and both are merged.
Author
Owner

@lunny commented on GitHub (May 18, 2017):

Please feel free to reopen this.

@lunny commented on GitHub (May 18, 2017): Please feel free to reopen this.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#488