Exiftool gui 5.14 damaged files

[noal]

Hi, well I´m pretty upset.
I wanted to strip metadata from 2 jpeg files which are in a folder with other subfolders containing my raw images. Now all of the raw files in subfolders are damaged and no raw software can read them, because exiftool gui (the latest v5.14) removed metadata even from the files in all subfolders containing a date with a dot in folder name. Without any warning at all! And no, there is no setting in gui.
So, beware if you do this. This is very serious bug. Please author fix it as soon as possible. Thank you for corrupting my images!

[Phil Harvey]

This is terrible.  If you didn't select "Don't make backup files" from the Options menu, then you should have backups of the originals that you can restore.

If not, there are things you can do to recover these files.  If you have backup JPG's with metadata (including MakerNotes metadata), you can try copying all metadata from the JPG's back to the raw images.  Otherwise, you can try copying just the MakerNotes and ExifIFD information from any other raw image to the file.  This technique should produce a readable file, although the color balance may be different and require some extra adjustment when developing.

But I'd like to know how this happened:  Was there an option to process subdirectories? What files/folders did you select before initiating this command?

- Phil

[noal]

Thank you for your prompt reply Phil. Unfortunately I don't have backup of these and my jpegs are without maker notes (they're from LR). But now I have found the way to fix this to some point by copying maker notes to those raws. Now I'm calmed a bit

And to your question: There was no option, it looks like some nasty bug. I only chose the parent folder in the left tree panel and then selected 2 single jpegs within this folder in the middle panel (I just moved them there just to have those 2 together). The parent folder contains also subfolders, where I have my raw files for client with dates in names separated by a dot and that dot is the problem ( folder name like [2012.11] ). Otherwise it behaves correctly without affecting any subfolders (if folder is like [201211] ). It happens with the new version 5.14. The old one 3.37 is ok.
Thanks for being helpful.

[Phil Harvey]

Thanks for explaining.  This definitely sounds like a problem with the GUI.  Unfortunately Bogdan hasn't been around lately, so unless he comes back this may never get fixed in ExifToolGUI 5.x.

- Phil

[BogdanH]

Hello everyone

This is serious bug.. I'm sorry I didn't noticed it before. Short explanation perhaps:
If in GUI "Show ALL files" filter is chosen (default) and all files are selected for modification in filelist pane (note: if there's only one file in directory, and that file is selected, then that means "all" files are selected), then ExifToolGUI uses wildcard expression:
exiftool -All:All= *.*

Now, if this command is used either in GUI or from console window, then that will affect also content in subfolders if some of them contains "dot" in folder name -that's how ExifTool works. I must say, that's not what Windows user would expect. For example, if I execute the following cmd-line command:
del *.*
-then only files will be deleted (not subfolders which may contain a dot in their names).

Anyway, the problem is "academic for end user, I think.. In short, I modified GUI, so it doesn't use *.* wildcard anymore. This has some (minor) speed impact if large amount of all files in directory is selected.. but there's no other solution.

Here's ExifToolGUI v5.15 attached.. Phil, please move it somewhere, so it will shown as "latest" version (I've lost access to your server). Thank you very much

Again, sorry for troubles caused by this bug.

Bogdan

[Phil Harvey]

Hi Bogdan!

It's great to hear from you again!!

Thanks for the update!

I'll move it into place tomorrow if you haven't done so already.  You should still be able to access the server, but I'm guessing that you tried when I had ssh disabled for about an hour earlier today (to discourage an ongoing hacker attack).

- Phil