Problem with writing metadata to JPG

I have some JPG-files where I can't write tags/comment to the files. It's possible that I corrupted the files somehow when writing/deleting tags to them by a script. The metadata for "example.jpg" are written to a temporary file "example.jpg5680" that persists in the folder but aren't applied to the original file. When using the metadata panel I get an "unknown error " message.
What went wrong with these files and how can I repair them and avoid to damage them again?
Error message and Example.jpg attached.

Can you give us a step-by-step way to reproduce what you're seeing?

I simply select the image with the metadata panel open and write a string to the tags or comment field. Clicking on "Apply" throws the error message and leaves the temporary file in the folder.

With all JPGs or just some? If just some, please upload one for us to try with.

Is it happening on all drives / destination types, or only particular ones?

Hm, the image i uploaded in my first post was one of the damaged ones but downloading it from here it's repaired. I copied the file from a standard HDD to a SSD. No network, virtual folder or such involved. It only happened to 2 files from 114.
Here's the same file from my first post in a zip. (439 KB)

I also encountered JPG files ending with numbers like in your example "example.jpg5680" in the past. For some time, the official explanation was that affected JPG files were readonly or secured by ACL, so DO or the library it uses to set the metadata is not able to succeed and fails. Unfortunately this can leave some of the files behind with that numbers added at the end. Later I did more testing and while it still might be related to read-only or permission denied, it can happen randomly as well. If you test on the same 200 jpgs several times, there will be different files with that 4-digit number appended each time. Recently it got better, iirc there was some kind of related fix as well.

For me it seemed to happen only when exif-rotating and reducing jpg quality and I got no error requester of any kind. Might be a totally different issue, but maybe not. o)

This is a problem I have seen from time to time. Making it happen, however has proved a thankless task. Fortunately it is not a regular occurrence. I may see it today and not see it again for a month.
I find that if I rename the files by knocking off the number, all is well and the metadata has, in fact been changed. By the way, I change the metadata by means of a VB script.
What tbone is saying matches my experience. It used to be a fairly regular occurrence with PSD files, but not any more.

Some more insight, perhaps, and a sample image which exhibits the same problem described by others above. In my case I copied a bunch of images from my Samsung S6 to my PC. Most of them are fine but two of them can not be tagged. Apply raises an error as shown below. One of the problem images is attached in a zip. The only obvious difference between the two that fail and the rest is that the former have _001 suffixes appended to their filenames on the camera. (4.6 MB)


That file seems to be corrupted in some way.

$ exiv2 -pa ~/Downloads/20180104_143102_001.jpg >/dev/null
Warning: Directory Photo has an unexpected next pointer; ignored.
Warning: Directory Photo, entry 0x0000 has unknown Exif (TIFF) type 0; setting type size 1.
Error: Upper boundary of data for directory Photo, ...
... entry 0x0000 is out of bounds: Offset = 0x00000001, size = 303109, ...
... exceeds buffer size by 280109 Bytes; truncating the entry

The _001 filename suffix may be indicative that something went wrong while the image was being saved.

I downloaded aussieboykie's file and unzipped it. Apart from the fact that Opus displayed it rotated in landscape mode and Photoshop did not, it behaved perfectly when I added metadata to it in both Opus and Photoshop.

I add metadata to a great number of pictures and I do still occasionally see the problem originally complained of.

In general when I add metadata to a file, the file flickers as the temporary file is created and then (I assume) is written over the original.

However, if the system is under considerable load, I can actually see the temporary file appear in the Lister for a couple of seconds. Normally it is written over the original and all is well. But I suspect that sometimes, for some reason, this operation cannot take place and you are left with the temporary file containing the amended metadata. Hence; when you knock off the numbers of this file which appear after the extension you have the file with the amended metadata.

This sequence happens every time I have a metadata write failure of this type.

This is a theory based solely on observation, so could be be total rhubarb, but perhaps trying to blame the problem on corrupt images may be the wrong tack.

I'm assuming the _001 suffix actually came from aussieboykie's phone, not from Opus.

The file is corrupt which explains the error he (and I) received when trying to add tags to it.


You are quite right Jon the image is corrupt in some way.

Apologies for that red herring. But I still believe their may be some merit in my observations about the temporary files.