User profile images unexpectedly deleted

Can you add the steps to reproduce to the issue summary please?

I can't figure out why this would happen, this isn't really related to the user module or so since it's a normal image field.
When uploading, I don't see the status being set to temporary either.

If this is still happening, it's critical because of the data loss. We can leave it filed against user.module for now (no need to file a separate issue against a different component within the core queue).

This might be an effect of #2787187: Data loss: Deleting a translation of an entity deletes all file_usage entries for files referenced by the entity .

Well, nothing in the summary suggests the user is being translated.

There was also a previous bug #2725415: Text Editor module fails to track usage of images uploaded in text_with_summary fields, allows uploaded images to be deleted but that was specific to images used in long text summaries with CKeditor, which would not apply here.

Then there is #1239558: Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger which could result in unused images being listed in general, but users are also not revisioned by default, so that also seems unlikely.

I think I just managed to reproduce this somehow with an image field:

The two things I did were rename a file, and rely on the file munging for a file with two extensions. Going to try those two things separately on a new install and see which is reproducible.

Edit: Not actually the bug.

Never mind, in #13, the files are actually named differently, and I confirmed that when temporary files are purged, the permanent file still remains.

So the screenshot attached above is not actually enough to confirm that the original report cause the file to be marked as both temporary and permanent. /admin/structure/files displays the name of the file, which is not the same as its filepath. To confirm there were actually two entries for a single file using that view, one would need to look at the links displayed and confirm they are the same file.

There are a lot of steps that would seem unrelated in the summary, but I wasn't able to reproduce this, so I tried the following.

1. Install Standard.
2. Go to /admin/config/media/image-styles and add a "User picture" image style that resizes the image to 85 x 85.
3. Go to /admin/config/people/accounts/fields and add a date field for the user's birthday.
4. Go to /admin/config/people/accounts/fields/user.user.user_picture and upload a default user picture.
5. Go to /admin/config/people/accounts/display and change the image style to the "User picture" one.
6. Add a user that has no picture (so uses the default).
7. Add an additional user account with a custom picture.
8. Leave user 1 using the default picture.
9. Add the user picture to the people view, using the user picture style.
10. At /admin/config/development/configuration/single/import:
    • Select "Simple configuration".
    • Add system.file as the configuration name.
    • Paste in:
      

      allow_insecure_uploads: false
      default_scheme: public
      path:
        temporary: /your/tmp/filepath/here
      temporary_maximum_age: 1
      _core:
        default_config_hash: your_config_hash_here
      

      (Use the filepath and default config hash from your system.file config. You can see it by going to the single export tab and looking at the same system.file config.)

    Save. This overrides your temporary file purge time to be 1 second, meaning temporary files are essentially deleted immediately when you run cron.

11. Run cron from /admin/reports/status.
12. Return to /admin/people. Nothing has been deleted.

So I think we need some other steps to reproduce this, and maybe some more specifics for the original report in the summary. Such as:

• What are the exact file paths of the images involved? Is it related to particular dates, etc.?
• Are the source image files deleted, or only the image style files?
• What do their entries look like in the file_managed table? Are there still entries there after the problem starts happening?
• Are there other specific configurations different from Standard?
• Were any images or accounts deleted through the UI?

Alternately, if anyone can find a different (less complicated) path to reproduce this, that would really help. Maybe someone who is having the problem could set up a simple site and monitor it and debug with it, then report back here.

I have a client reporting the same behaviour on the file upload form. Can't reproduce it also

@yobottehg, a few questions that might help diagnose it:

1. What kind of a file upload is it on the client's site? A user picture? Another image field? Or just a non-image file field?
2. What configuration options does the file field have? Max size, extension, etc.
3. Are the files that are being deleted unexpectely being used anywhere else on the site? E.g., referenced in other items of content, uploaded separately to other content, embedded in WYSIWYGs, etc.
4. Are the entities that are having the files deleted revisioned? Translated?
5. Do they see the files listed at /admin/content/files? (Keeping in mind that the displayed file name does not necessarily have the counters like _0 so they need to check both the name and the link to the file.)

Last summer (July 2015) I debugged a similar problem with files disappearing from the system somehow.
This has been files attached to a regular node form though.

I observed the following things:

• Some files got removed when being in temporary state. Some of them got lost from the {files} table, but some remained
• The related nodes seemed to be edited recently
• The effect was hard to track down, because a varnish cached the files for a long time, so it started to fail when something try to generate an image style

There seems to be indications that its related to the wysiwyg editor, see #2806287: Wysiwyg uploaded images disappear

suscribing

I have also faced this same issue on multiple sites that I have worked with. It has only happened few times and I have no clues what has caused it to happen.

@lauriii
Did you had more than one language on the site?

@dawehner yup, all of the sites where I have seen this to happen has been multilingual

Maybe this can be usefull, are steps to reproduce an unexpected image lost for image fields in multilingual sites: https://www.drupal.org/node/2810355

Hi, First i wanna say that im sorry for my bad english.
im a very new guy with Drupal, im using D8.2.5. And im having the same issues. But my problem its happening when i install a new language on my page and the logged in user change the default language on her page, the avatar dissapear, But only if he change the language. The others user have not problems.
Sorry, i can not help more because im new in Drupal, but i wanna share my problem so maybe can help somehow.
Thanks!

#28: thank you so much for posting that! Your information confirms exactly what I suspected:

its happening when i install a new language on my page and the logged in user change the default language on her page, the avatar dissapear, But only if he change the language. The others user have not problems.

Then the steps to reproduce are:

1. use the "user picture" field
2. user X uploads a photo to their "user picture" field
3. install a new language (note this can be a new interface language — you don't need to have content_translation installed!)
4. user X changes their preferred language
5. user X' user picture disappeared!

This is because \Drupal\user\AccountForm::form() does:

    // User entities contain both a langcode property (for identifying the
    // language of the entity data) and a preferred_langcode property (see
    // above). Rather than provide a UI forcing the user to choose both
    // separately, assume that the user profile data is in the user's preferred
    // language. This entity builder provides that synchronization. For
    // use-cases where this synchronization is not desired, a module can alter
    // or remove this item.
    $form['#entity_builders']['sync_user_langcode'] = '::syncUserLangcode';

Which means that \Drupal\user\AccountForm::syncUserLangcode() is called upon saving the account form, which then does:

  public function syncUserLangcode($entity_type_id, UserInterface $user, array &$form, FormStateInterface &$form_state) {
    $user->getUntranslated()->langcode = $user->preferred_langcode;
  }

… which means that the default translation is being changed!

This is exactly the same problem as #2810355: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted then.

Thanks to #28, I was able to prove this conclusively.

This is now merged with #2810355 — see #2810355-40: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted.