Bug #1227
File extension Issue
0%
Description
Randomly Digikam (5.1.0) seems to create a file with .JPG4392 (or other numbers) after tags are updated. The issue is that the actual image file is not updated with the change.
Can you please advise what this issue is.
Files
Related issues
History
Updated by Robin Mills about 5 years ago
- Assignee set to Robin Mills
- Target version set to 0.28
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
- Can you think of anything special or unusual about your setup?
To make progress with this, I need details such as:
- Which version of Exiv2 are you using?
$ exiv2 -vV - Your platform (Windows, Linux or Mac)
- How was the code built?
- An image file which exhibits the behaviour that you describe.
Robin
Updated by Robin Mills about 5 years ago
- Category set to insufficient information
- Status changed from New to Closed
- Target version changed from 0.28 to 0.26
- % Done changed from 0 to 100
- Estimated time set to 1.00 h
Updated by Henk van den Berg about 5 years ago
- File Singapore2012IMG_1274.jpg2184 Singapore2012IMG_1274.jpg2184 added
- File Singapore2012IMG_1274.jpg2184 Singapore2012IMG_1274.jpg2184 added
Thanks for your feedback and I will try to provide you context on the set up.
Three computers: 2 Windows PCs and 1 Mac
Files are located in a dropbox
Virus 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 upgrade
Please find attached a sample of an image and file
Please let me know if you have any further questions and hope this helps.
Henk
Updated by Robin Mills about 5 years ago
- Status changed from Closed to Assigned
- Assignee changed from Robin Mills to Gilles Caulier
- Target version changed from 0.26 to 0.28
- % Done changed from 100 to 0
I'm very suspicious of Dropbox. It could lock your files. Is this happening on the Mac, or Windows or Both? Which version of Windows or Mac?
I no longer support digiKam. They have demanded and wasted lots of my time. Other members of Team Exiv2 may help. I'm assigning this to Gilles Caulier who is the Lead Engineer for digiKam.
Updated by Niels Kristian Bech Jensen about 5 years ago
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.
Best regards,
Niels Kristian Bech Jensen
Updated by Robin Mills about 5 years ago
Niels:
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.