Commons:Deletion requests/Files created by User:Farawayman

Add {{delete|reason=Fill in reason for deletion here!|subpage=Files created by User:Farawayman|year=2024|month=December|day=18}} to the description page of each file.
Notify the uploader(s) with {{subst:idw||Files created by User:Farawayman|plural}} ~~~~
Add {{Commons:Deletion requests/Files created by User:Farawayman}} at the end of today's log.

This deletion discussion is now closed. Please do not make any edits to this archive. You can read the deletion policy or ask a question at the Village pump. If the circumstances surrounding this file have changed in a notable manner, you may re-nominate this file or ask for it to be undeleted.

Files created by User:Farawayman

Request for deletion is by me, creator of the photos User:Farawayman. Photos were uploaded with Exif data containing name and email address and as one cannot over-write images on Wikimedia, I request these to be deleted. I have already uploaded similar images (refer image file names "Dhaka Christian Cemetery 202211-nn" where nn=1 to 42. Those replacement images contain no personal Exif data. Links on Wiki site that reference the above files have been re-directed to the replacement files.

Please delete ASAP.

Farawayman (talk) 06:31, 25 November 2022 (UTC)[reply]

@Farawayman Actually, you can overwrite images on Wikimedia Commons. In cases like this, where you are simply removing personal information from the metadata, it is usually better to overwrite instead of uploading under a new name. But since you have already uploaded under new names, it would now be better to delete these (after verifying that they are not in use). Brianjd (talk) 15:28, 27 November 2022 (UTC)[reply]

@Brianjd I tried to overwrite but there was a warning to say that it was not possible to do so. I am assuming that’s because the Exif data make the photo unique, making any overwrite impossible, except by the same photo! Farawayman (talk) 02:03, 28 November 2022 (UTC)[reply]

@Jeff G. You seem knowledgable about abuse filters. Can you explain what is going on here? Brianjd (talk) 09:02, 29 November 2022 (UTC)[reply]

@Farawayman: The note at COM:OW states "A file can be overwritten by any user with an account older than 4 days from the file's file description page using the Upload a new version of this file link below the File history; or via Special:Upload. Special:Upload provides two warning messages when overwriting an existing file – MediaWiki:UploadFormPreviewOverwriteError and MediaWiki:Fileexists (see also Phab:T41344). The UploadWizard does not allow overwriting of files." Please be more specific about what you experienced, and if necessary contribute to that Phabricator task or make a new one. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 12:16, 30 November 2022 (UTC)[reply]

Jeff G. Thanks for all the interest and feedback - but its not possible to overwrite the original file. I thought it may be because I am using a VPN, stopped that - but symptoms are still the same. Details again:

I uploaded an image - photo taken by myself.
I neglected to purge the Exif data from the photo before I uploaded it.
I went back to the original images - re-exported them form Lightroom removing all Exif data.
Came back to WikiMedia intending to over-write the original image with the second, “Exif purged” image. WikiMedia does not permit me to over-write the original image. See below. This is one of the files (20221119-27)in the above list:
This is a error tracking screenshot related to deleting file with detailed Exif data
Above is an example of today - so status still persists.
To circumvent this, I uploaded new images, with Exif purged - and now (a week ago) I am requesting the original files to be deleted.
Only reason I can imagine is, because the detailed Exif data [name, place, camera type, f-stop, shutter-speed, email of creator etc, all related to the original image - makes it totally unique and hence it cannot be over-written, except by the identical photo with same Exif data. Else you are overwriting with a different image.
One issue is to resolve the reason for not being able to over-write the original files - that’s a bug or an error in the way I am approaching matters. Main issue is to delete the original files, because even if I were able to over-write them, I have already created parallel, Exif purged files!! (And then we would need to delete those….)

Hope this makes sense? Farawayman (talk) 13:53, 1 December 2022 (UTC)[reply]

@Farawayman This might seem a bit silly, but did you make sure you were logged in when viewing the file description? Brianjd (talk) 06:08, 2 December 2022 (UTC)[reply]

@Farawayman The screenshot wasn’t licensed properly. I’m not sure if it’s right now, but it definitely wasn’t right before (claimed {{Own}} / {{self|cc-by-sa-4.0}}). Normally I wouldn’t bother, but I think this screenshot might be useful in its own right, assuming we don’t already have a better one. Brianjd (talk) 06:13, 2 December 2022 (UTC)[reply]

@Farawayman: I am allowed to "Upload a new version of this file" for File:Dhaka Christian Cemetery 202211-27.jpg (which only has horizontal and vertical resolution metadata, as opposed to the original version of File:Dhaka Christian Cemetery 20221119-13.jpg) while logged in. File:Overwrite and chunked upload links.jpg is what it looks like to me. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 10:52, 2 December 2022 (UTC)[reply]

You may now officially call me a moron! I suspect that I was logged in to Wikipedia, but probably not to WikiMedia! I double checked login status now, and I was able to overwrite an image - see xxx-13 above. Question, if I overwrite all of the above, we have duplicate images (as we now do with xxxx-13). So, as the “error issue” is resolved, I guess the best solution is speedy deletion? Apologies for all the wasted time. Farawayman (talk) 11:16, 2 December 2022 (UTC)[reply]

@Farawayman: How about we call you a student? You may overwrite your other photos which have significant metadata and withdraw this request. You may then ask for an Admin to hide (revdel or revision delete) the old versions, if they have not done so already. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 11:34, 2 December 2022 (UTC)[reply]

@Jeff G. Normally, that would be a good solution. But since the uploader has already uploaded the files under new names and (according to the uploader) the original names are not in use, should we now proceed with the deletion? Brianjd (talk) 12:39, 2 December 2022 (UTC)[reply]

@Brianjd: Ok,

Delete per discussion. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 12:54, 2 December 2022 (UTC)[reply]

Thanks Guys - above is correct, replacement images have already been uploaded and linked to appropriate Wiki pages. Those images in above list should be deleted. Lesson learned.... thanks. Farawayman (talk) 07:30, 3 December 2022 (UTC)[reply]

@Farawayman and Jeff G.: Should the old files be kept as evidence of copyright status? I thought not, until I saw Commons:Deletion requests/File:Love River.jpg and Commons:Deletion requests/File:Taishan 1.jpg. Now I’m confused. Brianjd (talk) 11:01, 3 December 2022 (UTC)[reply]

@Brianjd and Farawayman: I don't think so, but Nw520 may have a different opinion. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 15:08, 4 December 2022 (UTC)[reply]

@Jeff G. Do you mean that MGA73 may have a different opinion? Brianjd (talk) 15:14, 4 December 2022 (UTC)[reply]

@Brianjd: Both may have opinions on the matter - the more the merrier. Keeping files that are marred by destructive watermarks is an acceptable nuisance, while keeping files that have metadata which reveals the uploader's name and email address is a violation of the uploader's privacy if the uploader wants to keep that info private. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 15:29, 4 December 2022 (UTC)[reply]

@Jeff G. Of course the uploader is entitled to have their name and e-mail address removed, but the way they went about it was to have all the metadata removed, and I find that a bit troubling. Brianjd (talk) 15:37, 4 December 2022 (UTC)[reply]

If the answer is yes, then this should be documented at COM:Redundant (or similar) per Commons:Deletion requests/File:Guanghuatempel.jpg. Brianjd (talk) 15:41, 4 December 2022 (UTC)[reply]

@Jeff G. Surely if I as the creator of the image elect to have that image uploaded to Wikimedia - I have the right to decide which MetaData I choose to distribute together with the photo? Like the image, the accompanying metadata (exif data in this case) contribution is my choice. I elected to not have metadata with my personal information being made visible. To correct this, I uploaded identical images to the first batch - but with no metadata present, and am now requesting the first batch with the "offending metadata" to be deleted. The reference to Commons:Deletion requests/File:Love River.jpg and Commons:Deletion requests/File:Taishan 1.jpg appear to be retained originals where subsequent versions were uploaded and the original was overwritten. This was not the case here - new files were created in batch 2 with a new file-name. See File:Dhaka Christian Cemetery 20221119-10.jpg and File:Dhaka Christian Cemetery 202211-10.jpg - same image, new filename with full Creative Commons 4 release (but no exif data). Im not sure how that could be considered "troubling" - what is troubling is that those images with personal exif data have not yet been deleted, while this philosophical debate continues! Let's remedy that first and then discuss this subject later. Farawayman (talk) 16:38, 4 December 2022 (UTC)[reply]

@Farawayman: Deletion requests here normally live at least 7 days until closure by an Admin; the oldest live one is Commons:Deletion requests/Files uploaded by Basilicvegeta7120 from 12:06, 18 July 2022 (UTC). Pinging @Brianjd, who appears to be the subject of your comment. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 17:28, 4 December 2022 (UTC)[reply]

@Farawayman I don’t know what overwriting you are referring to, as the four files referenced in the other DRs each have only one version.

I said that the removal of all metadata (not just the personal information) was troubling because it was unnecessary (although it may sometimes be necessary for technical reasons) and a lack of metadata often creates copyright suspicions. Brianjd (talk) 04:23, 5 December 2022 (UTC)[reply]

Comment @Jeff G. and Brianjd: Thank you for the ping/question regarding keeping older versions as proof. The reason I think we should keep the old files mentioned in the DRs above is that the files were originally uploaded on an external website. They were imported to Commons with reference to original upload log etc. Deleting the files will not save any space so there is very little or no gain deleting the files. The files in this DR are originally uploaded to Commons so admins can at all time view original info in case someone find a copy of the file uploaded on an external website before the new version was uploaded. We do not save any space but we hide personal information so I think that makes a difference. The best solution would have been to upload a new version and hide the old but that is no longer relevant. So I think we can only chose between deleting the old files or merge old/new and hide old. --MGA73 (talk) 16:30, 5 December 2022 (UTC)[reply]
@MGA73, Farawayman, and Jeff G.: I did not think of merging. Is that a good idea? Brianjd (talk) 10:42, 6 December 2022 (UTC)[reply]
@Brianjd, Farawayman, and MGA73: I think merging is the best way forward, using the original filenames because they have the day of the month "19" included and they are more likely to have external uses. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 11:42, 6 December 2022 (UTC)[reply]
@Jeff G. Sounds good. ~~Even better, if they display a deleted revision and a live revision with a summary like removed metadata, then users will understand why there is no metadata.~~ (Actually, I don’t think that’s possible now unless someone manually uploads all the files a third time.) Brianjd (talk) 11:53, 6 December 2022 (UTC)[reply]
@Brianjd: There will already be a reference to this DR in the history of each file description page and on each file desription page's talk page, that should be enough. — 🇺🇦Jeff G. ツ_{please ping or talk to me}🇺🇦 12:17, 6 December 2022 (UTC)[reply]
@Jeff G. But that’s only true if the files are merged. So I was on the right track with my comment above. Brianjd (talk) 12:22, 6 December 2022 (UTC)[reply]
@Brianjd: Merge makes sense - Can you please point me to instructions on how to merge images? Couldn't find any help page related to that. Farawayman (talk) 04:15, 8 December 2022 (UTC)[reply]
Only an administrator can merge histories, but any user can request this; see Commons:History merging and splitting. But it’s probably not a good idea to open a request there while this discussion is still open. Brianjd (talk) 05:57, 8 December 2022 (UTC)[reply]
Forgot to ping @Farawayman. Brianjd (talk) 06:00, 8 December 2022 (UTC)[reply]
Thanks, noted. So please merge or delete. Farawayman (talk) 03:33, 10 December 2022 (UTC)[reply]

Can we now please delete the offending images? Its been five months!!! Farawayman (talk) 01:26, 10 March 2023 (UTC)[reply]

Deleted: per nomination. --Krd 12:31, 8 April 2023 (UTC)[reply]

Commons:Deletion requests/Files created by User:Farawayman

Files created by User:Farawayman

Navigation menu

Search