Image Converter - tmp filename issue?

Hi guys!

It's been for some years for me now, that the DO image conversion is irritated by something and forgets/is not able to rename the final image file I guess.
Please have a look at the screenshot, it shows images from the year 2012 on. They all have trailing numbers, which were not part of the original filename before the conversion.
Because it happened again for me today, I thought it's time to address that now. o)

It can happen by using the converter dialog for single image operations, but will most oftenly happen when running actions on a bunch of files.

I regularly remove trailing numbers from filenames manually (if the described happens), so the list of files shown here is not the actual number of files being affected for me since 2012.
It may even have occured before that time, I may have been more carefully for watching the results back then.
The problem occurs on approximately 0-3% percent of images I push through the image converter and does not seem to be reproducable for the same files.

Maybe you can guess what's going on by seeing that familiar tmp-suffix or something?

Thanx! o)


That can happen if something goes wrong during the conversion and it aborts part-way through. It may be a bug.

(It could also happen it something blocks the rename, e.g. something else monitoring the folder for changes, antivirus, misbehaving network drives, etc.)

Does it only happen with images from a specific source and/or when doing certain conversions? What's the best way for us to try and reproduce it?

Compare

It is much better now, although i occassionally (quite rarely) still can see that effect.

Well, I can say that:

  • I'm 99% in DUAL mode when doing image conversions
  • I nearly always have a conversion running, where jpg quality is to be reduced to 85 and exif rotation is done
  • there's no network involved (work is always done on the same partition or I copy/convert in one go from sd-card to disk)
  • there's no antivirus running
  • the exif-orientation of the image has no influence (landscape and portrait affected)
  • the actual command I run is: Image CONVERT=jpg PRESERVEDATE ROTATE=EXIF REPLACE=always QUALITY 85 NOLOSSLESS NOREDUCE
  • it does happen when using the converter dialog too, replacing images in place and again using jpg-quality reduction
  • it seems to occur very more often, if I "stress-test" DO while the conversion is running (hitting F5 and toggling between thumbs/details rapdily for the destination lister)

Out of 40 files I was able to get 3 "misses" when doing the stress-test some minutes ago. Not touching DO while converting gave no errors.

EDIT: Had another stresstest, hitting F5 and thumbnails/details toggle at the same time (by mouse) gave 5 misses - highscore! o)
Hitting F5 alone seems to not raise errors, heavily toggling thumbs/details may result in 1-bad 2 files.
The combination of both probably is the best way to reproduce it, but there are always different files affected.

Thank you! o)


@abr
Whoo, looks very similar to this topic, interesting - thx! o)

Addition:

  • If I use the converter dialog, I open it like so: Image CONVERT HERE REPLACE NOLOSSLESS, because jpg quality cannot be reduced in place if one of these switches is'n present.
  • notice the digits added to the filename being the same for the running task, but may be different next day/folder or whatever these depedent on.. o)

Do you still see this? We found it could happen with read-only files, where the renamed copy of the original file failed to be deleted. That's fixed now. Maybe that was what was happening.

The "cleaning up" is reliably working for a long period of time now, at least for my usecase.

I converted around 1000 images before yesterday and had no strange effects at least.

Time will tell I guess, but I always had the impression, that this problem is related to something not as easy to determine as the read-only attribute on a file (see results of the stresstest). It's more like there would be temporary locks because the viewerpane interferes or something. It also happened for me on files, for which I had no delete but write/read permission only.

That would still happen, and can't really be avoided. We keep the old file in case there's a problem writing the new file, and only try to delete it once the new file is successful, so if you can't delete the old file then it won't be deleted.