Page MenuHomePhabricator

Original version of File:2008 scalpelless vasectomy, post-op.JPG has disappeared
Closed, ResolvedPublicBUG REPORT

Description

The original version of https://commons.wikimedia.org/wiki/File:2008_scalpelless_vasectomy,_post-op.JPG (contains nudity) seems to have disappeared. This file is in use on the German Wiktionary and an enwiki talk page.

As a (hopefully) temporary measure, I have uploaded the thumbnail from https://web.archive.org/web/20191006111343/https://commons.wikimedia.org/wiki/File:2008_scalpelless_vasectomy,_post-op.JPG. Unfortunately, it looks like the Internet Archive does not have the original.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

It's a little difficult to see what might have happened here, since you've overwritten the "original" path. The only log entries for that I can find in swift in the last few days (i.e. all the logs we've kept) that aren't GET or HEAD are the two PUTs from your upload on at 2023-09-04 00:56:03.

Searching in backups for 2008_scalpelless_vasectomy,_post-op.JPG just finds me backups of the file you uploaded. But I do notice that that file notes a redirection from DSC_0204.JPG, and we do still have that as a deleted object:

wiki                 | commonswiki
title                | DSC_0204.JPG
production_container | wikipedia-commons-local-deleted.ge
production_path      | g/e/b/gebtj7wmizln809hhw7cth9fxlg6x2q.jpg
sha1                 | 8c6169221e33cb1857f183d46bb4d6d9177240f2
sha256               | 67a13e54c0c5631e11e391af452b7fb04c9327df9cbef924daa9e52c567da5fb
size                 | 768073
type                 | BITMAP
production_status    | deleted
production_url       | None
upload_date          | 2011-04-24 15:39:59
archive_date         | None
delete_date          | 2012-06-10 18:26:57
backup_status        | backedup
backup_date          | 2021-09-18 13:52:36
backup_location      | https://backup1005.eqiad.wmnet:9000
backup_container     | mediabackups
backup_path          | commonswiki/67a/67a13e54c0c5631e11e391af452b7fb04c9327df9cbef924daa9e52c567da5fb

As I understand it, a suitably privileged editor could undelete that object (which would be the original you want, albeit with the wrong filename).
@jcrespo might be able to advise if it's possible to see what backups thought about the missing image (and/or what mediawiki thought about its state) before you uploaded the thumbnail over the top.

Completing what @MatthewVernon correctly says, there are my findings:

root@db1204.eqiad.wmnet[mediabackups]> select * FROM files where sha1='8c6169221e33cb1857f183d46bb4d6d9177240f2'\G
*************************** 1. row ***************************
                id: 10870694
              wiki: 392
       upload_name: 2008_scalpelless_vasectomy,_post-op.JPG
 storage_container: 278
      storage_path: 1/10/2008_scalpelless_vasectomy,_post-op.JPG
         file_type: 2
            status: 1
              sha1: 8c6169221e33cb1857f183d46bb4d6d9177240f2
               md5: NULL
              size: 768073
  upload_timestamp: 2011-04-24 15:49:07
archived_timestamp: NULL
 deleted_timestamp: NULL
     backup_status: 4
*************************** 2. row ***************************
                id: 87973960
              wiki: 392
       upload_name: DSC_0204.JPG
 storage_container: 5880
      storage_path: g/e/b/gebtj7wmizln809hhw7cth9fxlg6x2q.jpg
         file_type: 2
            status: 3
              sha1: 8c6169221e33cb1857f183d46bb4d6d9177240f2
               md5: NULL
              size: 768073
  upload_timestamp: 2011-04-24 15:39:59
archived_timestamp: NULL
 deleted_timestamp: 2012-06-10 18:26:57
     backup_status: 3
2 rows in set (0.001 sec)
root@db1204.eqiad.wmnet[mediabackups]> select * FROM backups where wiki=392 and sha1='8c6169221e33cb1857f183d46bb4d6d9177240f2';
+----------+------+------------------------------------------------------------------+------------------------------------------+---------------------+
| location | wiki | sha256                                                           | sha1                                     | backup_time         |
+----------+------+------------------------------------------------------------------+------------------------------------------+---------------------+
|        2 |  392 | 67a13e54c0c5631e11e391af452b7fb04c9327df9cbef924daa9e52c567da5fb | 8c6169221e33cb1857f183d46bb4d6d9177240f2 | 2021-09-18 13:52:36 |
+----------+------+------------------------------------------------------------------+------------------------------------------+---------------------+
1 row in set (0.001 sec)

Note the backup_status 3 means it was phisically backed up, while 4 means it was backed up but no new file was stored because it was redundant to an existing backup file.

  • Old metadata confirms that the file existed from the database point of view, before the new upload, but the new upload was unable to rename what probably was a non-existent file at the time:

Metadata 3 months ago: ("2008_scalpelless_vasectomy,_post-op.JPG",768073,3008,2000,"<metadata>",8,"BITMAP","image","jpeg",45962331,111995,"20110424154907","gebtj7wmizln809hhw7cth9fxlg6x2q")
Metadata now (including archival):

root@db1150.eqiad.wmnet[commonswiki]> select * FROM oldimage where oi_name = '2008_scalpelless_vasectomy,_post-op.JPG' limit 10\G
*************************** 1. row ***************************
          oi_name: 2008_scalpelless_vasectomy,_post-op.JPG
  oi_archive_name: 
          oi_size: 768073
         oi_width: 3008
        oi_height: 2000
          oi_bits: 8
oi_description_id: 45962331
         oi_actor: 111995
     oi_timestamp: 20110424154907
      oi_metadata: a:44:{s:4:"Make";s:17:"NIKON CORPORATION";s:5:"Model";s:9:"NIKON D40";s:11:"Orientation";i:1;s:11:"XResolution";s:5:"300/1";s:11:"YR>
    oi_media_type: BITMAP
    oi_major_mime: image
    oi_minor_mime: jpeg
       oi_deleted: 0
          oi_sha1: gebtj7wmizln809hhw7cth9fxlg6x2q
1 row in set (0.001 sec)

Note how oi_archive_name don't have a title which should be something like 2023090...!

So, further steps:

  • On the bright side, @AntiCompositeNumber - you do not have to worry about recovery or getting a copy somewhere- we have that on backups and I will upload here the version we have there and all its metadata. I promised after backups were enable that we didn't lose any file.
  • On the bad side, there is no logs or related activity, that we know of, that may have caused that loss (there was no wiki activity coinciding with that loss)

The file: F37653248 (note it is the original because it's sha1 is 8c6169221e33cb1857f183d46bb4d6d9177240f2 or gebtj7wmizln809hhw7cth9fxlg6x2q in the weird base36 wikimedia encoding). This was its original metadata:

("2008_scalpelless_vasectomy,_post-op.JPG",768073,3008,2000,"""a:44:{s:4:\"Make\";s:17:\"NIKON CORPORATION\";s:5:\"Model\";s:9:\"NIKON D40\";s:11:\"Orientation\";i:1;s:11:\"XResolution\";s:5:\"300/1\";s:11:\"YResolution\";s:5:\"300/1\";s:14:\"ResolutionUnit\";i:2;s:8:\"Software\";s:9:\"Ver.1.10 \";s:8:\"DateTime\";s:19:\"2008:03:21 22:54:56\";s:16:\"YCbCrPositioning\";i:2;s:12:\"ExposureTime\";s:6:\"10/600\";s:7:\"FNumber\";s:5:\"56/10\";s:15:\"ExposureProgram\";i:0;s:15:\"ISOSpeedRatings\";i:400;s:11:\"ExifVersion\";s:4:\"0221\";s:16:\"DateTimeOriginal\";s:19:\"2008:03:21 22:54:56\";s:17:\"DateTimeDigitized\";s:19:\"2008:03:21 22:54:55\";s:23:\"ComponentsConfiguration\";a:5:{i:0;i:1;i:1;i:2;i:2;i:3;i:3;i:0;s:5:\"_type\";s:2:\"ol\";}s:22:\"CompressedBitsPerPixel\";s:3:\"1/1\";s:17:\"ExposureBiasValue\";s:3:\"0/6\";s:16:\"MaxApertureValue\";s:5:\"50/10\";s:12:\"MeteringMode\";i:5;s:11:\"LightSource\";i:0;s:5:\"Flash\";i:29;s:11:\"FocalLength\";s:7:\"2000/10\";s:10:\"SubSecTime\";s:2:\"60\";s:18:\"SubSecTimeOriginal\";s:2:\"60\";s:19:\"SubSecTimeDigitized\";s:2:\"60\";s:15:\"FlashPixVersion\";s:4:\"0100\";s:10:\"ColorSpace\";i:1;s:13:\"SensingMethod\";i:2;s:10:\"FileSource\";i:3;s:9:\"SceneType\";i:1;s:14:\"CustomRendered\";i:0;s:12:\"ExposureMode\";i:0;s:12:\"WhiteBalance\";i:0;s:16:\"DigitalZoomRatio\";s:3:\"1/1\";s:21:\"FocalLengthIn35mmFilm\";i:300;s:16:\"SceneCaptureType\";i:0;s:11:\"GainControl\";i:1;s:8:\"Contrast\";i:0;s:10:\"Saturation\";i:0;s:9:\"Sharpness\";i:0;s:20:\"SubjectDistanceRange\";i:0;s:22:\"MEDIAWIKI_EXIF_VERSION\";i:2;}""",8,"BITMAP","image","jpeg",45962331,111995,"20110424154907","gebtj7wmizln809hhw7cth9fxlg6x2q"),

My recommendation is to upload the original attached here as the latest version with a link to this ticket, rather than trying to undo all changes, as metadata history would complicate things (if a new version wouldn't have been uploaded, doing a transparent recovery would have been easier).

jcrespo triaged this task as High priority.Sep 4 2023, 1:30 PM

@AntiCompositeNumber will you upload the original file attached here? Not being an admin on commons, I cannot delete older revisions; although we could edit the metadata afterwards by tuning the database to leave it as it was before.

F37653248 was not attached to this ticket and I can not see it. I do see the deleted duplicate revision at DSC 0204.JPG and could restore from there.

I restored the image by copying from the duplicate. I do not think it is necessary to attempt to rewrite the history.

While it may have been possible for me to attempt a selective history merge from the redirect now that T244567 has been fixed, I did not attempt it because the deleted upload predates the missing upload. That would have meant I would have had to revert to the previous version anyway, resulting in the same outcome with more steps and a more confusing page history.