News:

2023-03-15 Major improvements to the new Geolocation feature

Main Menu

"file already exists" error (WINDOWS)

Started by Uli, August 01, 2012, 09:33:42 AM

Previous topic - Next topic

Uli

I made some tests with exiftool  v8.99, but could not see any difference.

My believe is that geosetter is causing the trouble (see below).

SCENARIO 1: ARW+XMP+JPG
My test setup:

  • original ARW (SONY A580)
  • sidecar files created by LR3
  • paired JPG modified by LR3
  • a few JPG from my old SAMSUNG L50
Files are located on system drive C:, or on 2nd drive.

I observed that having the geosetter overwrite checked the failure occours with a higher number of files. Thus I run all tests with this setting (for ARW sidecar and JPG).

I observed that the geosetter is doing some caching which leads to different results per run. That's another potential source of failure, because if the files are exchanged (e.g. by doing a 2nd export out of the library) geosetter seems to use the cached data. As a workaround I made a fresh copy of files in different named folders (geosetter was not running).

I observed that geosetter causes segmentation on my HDD. That's clear because geosetter starts different exiftool instances in parallel and all those instances try to use the single resource HDD. I guess the intention was to speed up storing the files, but now it blocks the HDD. B/s goes down dramatically and head is making noise like hell. I added a 2nd HDD which somehow brought down the noise.

At the end I developed some paranoia and made clean-up before each test run

  • recycle bin emptied
  • geosetter cache files deleted
  • fresh copy of files into indexed folder
  • check geosetter disappeared in the task manager

This gave me repeatable results.

My asumption is still that this many exiftool instances are causing the failur. The geosetter guys should add a switch to turn this feature of.

To prove my assumption I tried to block the HDD with a copy process by running FastCopy on real-time priority. That changed behavior of geosetter, as expected (more failures).

All failures are of type "Error: Temporary file already exists: F:/TEMP/xxxx_2012$18/DSC02689.xmp_exiftool_tmp". So no failures on the JPGs.


SCENARIO 2: JPG only
By removing the ARW+XMP files and only processing JPGs, having the geosetter overwrite checked the failure type is "Error: File not found - C:/temp/xxxx_2012$28/DSC02619.JPG"

Only once I observed a fully blocked geosetter (while it was storing by CTRL-S), while I was dropping a text file into the image folder. All the temporary files were frozen for almost one minute. Then the storing continued. Strange...

There were no problems when the geosetter overwrite was not checked.

At the end I re-enabled my virus scanner, but there was no difference.

My workflow now:

  • only process ARW+XMP and JPG separately
  • do not use overwrite
  • in case of error delete image folder, and re-run with a fresh copy
  • if this does not work split data by half
  • never ever use data directly from image library

Uli

I used the exiftool_stub to do some additional tests:

https://exiftool.org/forum/index.php/topic,3577.msg16282.html#msg16282

The batch file I used contains a random DELAY, and a call to the actual perl exiftool (in this order).

The delay is between 3000..6000msec (haven't verified this really, but progress bar of geosetter is much slower now).

The idea was to spread the exiftool-calls so that crashes are less likely.

The test run with same failure rate as before :(

X-check: Removing the DELAY, but keeping the indirect call via the stub shows same failure rate.

The error message in geosetter is different, but that might be because the exit() value is not passed properly back by the batch file.


Uli

Re-test Geosetter 3.4.16, ExifTool 9.03: same failure, plus one additional message after CTRL-S:

"It took 2 tries to rename C:/temp/FOLDER/SPA53794.JPG"