View Issue Details

IDProjectCategoryView StatusLast Update
0000642GeoSetterImage Datapublic2010-09-09 17:31
Reporterarthurb Assigned ToFriedemann  
PrioritynormalSeveritymajorReproducibilitysometimes
Status feedbackResolutionopen 
Product Version3.3.60 Release 
Target VersionFixed in Version 
Summary0000642: Geosetter, or ExifTool, is deleting image files
DescriptionVery frequently, but not every time, when I try to update Raw image files with GPS data, the process gives error messages and some files are not updated. However, some or all of those files are deleted!

A file of name image-filename.ARW_exiftool_tmp is left for each deleted image - I have been checking Phil Harvey's site but cannot see how, or even if, I can restore the missing image(s) for that 'temp' file.

This happens whether I am updating from GPS logs or from Google map data, and also occurs with both Sony's Raw and cRaw (compressed Raw) files.

I understand that this may be an ExifTool problem but I have to start with Geosetter first.

    
Additional InformationWindows XP
Single processor (AMD Athlon 64) and 2GB RAM

Sony ARW v2.0 files (from A700)

Geosetter error message panel has been appended

 

TagsNo tags attached.

Relationships

related to 0000705 feedbackFriedemann Gelöschte Bilder 

Activities

2010-09-07 21:12

 

2010-09-07_195644.png (21,834 bytes)
2010-09-07_195644.png (21,834 bytes)

Friedemann

2010-09-07 21:42

administrator   ~0001230

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?

arthurb

2010-09-08 01:36

reporter   ~0001231

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.

Friedemann

2010-09-08 15:58

administrator   ~0001232

> 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...

arthurb

2010-09-08 19:39

reporter   ~0001233

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.

arthurb

2010-09-09 02:35

reporter   ~0001234

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.

boardhead

2010-09-09 16:32

reporter   ~0001236

Last edited: 2010-09-09 16:34

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

boardhead

2010-09-09 17:31

reporter   ~0001237

By the way, what Norton is doing could be considered a DoS (denial of service) attack. Ironic, really.

Issue History

Date Modified Username Field Change
2010-09-07 21:12 arthurb New Issue
2010-09-07 21:12 arthurb File Added: 2010-09-07_195644.png
2010-09-07 21:29 Friedemann Status new => assigned
2010-09-07 21:29 Friedemann Assigned To => Friedemann
2010-09-07 21:42 Friedemann Note Added: 0001230
2010-09-07 21:42 Friedemann Status assigned => feedback
2010-09-08 01:36 arthurb Note Added: 0001231
2010-09-08 15:58 Friedemann Note Added: 0001232
2010-09-08 19:39 arthurb Note Added: 0001233
2010-09-09 02:35 arthurb Note Added: 0001234
2010-09-09 16:32 boardhead Note Added: 0001236
2010-09-09 16:33 boardhead Note Edited: 0001236
2010-09-09 16:34 boardhead Note Edited: 0001236
2010-09-09 17:31 boardhead Note Added: 0001237
2011-01-06 12:59 Friedemann Relationship added related to 0000705