History

Exiv2 creates temporary files using the name of the image file name and the process id. The metadata is created in this temporary file and when it has been successfully written, the metadata is copied to the original file and the temporary file is deleted. This approach is used to minimise the risk to your valuable original image file. It sounds as though there is something preventing the temporary file from being copied into your image file and it is being left behind for you to spot it. However your file is undamaged.

Here are questions you could consider:

Is it possible that your image is write protected (read-only)?

Is there a virus checker in use?

Have you seen this on another computer?

Is your file on local stored (e.g. Hard Drive) or is it on a Network Drive

Thanks for your feedback and I will try to provide you context on the set up.

Three computers: 2 Windows PCs and 1 MacFiles are located in a dropboxVirus checker: 1 Mac and 1 PC do not run a virus checking App. I will verify the if the second PC runs it.The application used is Digikam version 5.1.0. which is open standard. I am using the packaged version and I am not a developer. I reported the issue to them and they referred me to report the issue to Exiv. Digikam recently upgraded from 4.x.x to 5.x.x and I did not have the issue before the upgradePlease find attached a sample of an image and filePlease let me know if you have any further questions and hope this helps.

It seems to me that this issue, issue #1222 and this bug report from UFRaw: https://sourceforge.net/p/ufraw/bugs/409/ might be related. The common demoninator seems to be spawning processes/multi threading on the Windows platform. Could it be some sort of file lock mechanism playing havoc? I do not know anything about the Windows internals.

Thanks for stepping into #1222 and #1227 For sure, there's something nasty happening and it's going to take some time to discover what's at the bottom of this.

When I investigated #1207 for Gilles on MacOS-X, he asked me to use "a lot more than 3 threads". So I did. I got messages from the OS that I've never seen before about "resource not available". I've subsequently learned that MacOS-X has limits of about 256 open files per process. Those limits can be changed by the user, however that is not a useful fix. It's important that multi-threaded application control/limit the number of threads opening files. I think we'll learn that Windows requires similar treatment.

The Windows platform is also challenged by invisible processes such as Virus Checkers, Dropbox and other agents who may be locking the files. We are not alone. Something's going on.

Regrettably, I am flat out at present getting finished with v0.26. The test program samples/mt-test.cpp may be a useful starting point from which to investigate this issue.