|
2010-09-07 21:12
|
2010-09-07_195644.png (21,834 bytes) |
|
|
GeoSetter doesn't touch your files itself, it only calls ExifTool. Are you using perhaps an antivirus software which maybe blocks the temp files while processed by ExifTool? But it's very strange that your files has been deleted!!! Are there perhaps files like image-filename.ARW_original? |
|
|
Hello Friedemann, I believe that this problem (the intermittent deleting of files) occurs both when updating the files directly (i.e. with no .ARW_original file), and when updating indirectly (i.e. with a .ARW_original file). I have been doing a lot of testing of this with a selected set of images, but I will check further tomorrow (Wednesday 8/9), and definitively see if there is any difference between updating inplace and updating using ..._original files. Just thinking about that, is it true that if ..._original files are created then there should be no need for ..._exiftool_tmp files? Maybe there is some form of conflict here; perhaps both methods of updating are occurring and creating a conflict. Then again, maybe I'm just getting very tired as it is quite late. I don't think my anti-virus software (Norton) is involved, as I have seen nothing like this with any other programs running. I will do some more testing tomorrow, Regards, Arthur. |
|
|
> I don't think my anti-virus software (Norton) is involved But I'm pretty sure that it is. I found this in my mails regarding a similar problem: > It was Norton, so I think the problem was exactly what I assumed > already, a locking process while ExifTool is handling a file. > After excluding XMP files in Norton, all works fine, no errors anymore. Norton locks the files while ExifTool is still working on them... |
|
|
Hello again, it does look as though telling Norton to ignore the temp files has had the required effect. I will try to build a larger set of image files to test with and then try again - hopefully later this evening. Regards, Arthur. |
|
|
Hello yet again Friedemann, you were completely correct; changing the settings in Norton Internet Security has fixed this issue. I have done quite a few updates this evening with test data (27 images repeated 4 times with backup files and without) and then with images I wished to keep (83 files with backup i.e. ..._original), and had no errors. Thank you very much for pointing me toward Norton; as I said I have had nothing like this since installing NIS over 4 years ago. For anyone else reading this the fix was: Norton Internet Security --> Settings --> Computer Settings --> Exclusions/Low Risks --> Scan Exclusions (Configure)... Then in the Configure panel, in both Scan Exclusions and Auto-Protect Exclusions add a definition for all files of the temporary file type: *.ARW_exiftool_tmp I suspect that in this case the Auto-Protect process was the culprit, but I decided to do the scan as well. Once again, thank you Friedemann, and I am very sorry that I doubted your excellent software (and perhaps in this case Phil's). Thanks, Arthur. |
|
|
Even with the Norton problem I can't see how any image would ever be lost. I take great pains to avoid this. The logic is different if you use -overwrite_original or -overwrite_original_in_place. With these options there is a chance that the original file could be deleted with a "_exiftool_tmp" file remaining if the final rename failed. In this case, exiftool will abort with a "Error renaming" message and the temporary file is the final output file (which may be renamed by removing the "_exiftooL_tmp" to recover the file). The errors shown in your attached PNG will occur if you try to run the same command again. In this case exiftool will discover the temporary files and abort because the deleting the temporary file may result in a loss of data (as in this situation). If Norton opens the output file before exiftool can rename it, it could certainly cause this problem. - Phil |
|
|
By the way, what Norton is doing could be considered a DoS (denial of service) attack. Ironic, really. |
- Anonymous
