How Do I Verify a valid ExifTool installation ?

Started by rhenley, July 17, 2024, 06:57:28 PM

Previous topic - Next topic

rhenley

Once again I find that I'm creating another image tool which is using a deficient SDK as its base. I then thought that I would fill those problems, by using  ExifTool to run a spawned process to grab some metadata from the file. And hopefully see a way into the file deep enough to solve the original problems, since neither exactly agrees with the other in a way that's clear yet.

Unfortunately now I can 't see a simple way any longer to verify a valid existence of ExifTool with the new installation folder scheme.

..\ExifTool\exiftool-12.89_64\

Perhaps I'm missing something simple here, because I'm trying to solve a different data problem that I thought ExifTool would help me solve. But this new ExifTool installer is going to complicate its providential existence way out of where I want wish to be.

Before it was rather simple, if the EXE was in the installed directory then I thought it OK to forge ahead. But now in addition not exactly where it's going to be thanks to the vagaries of a deficient SDK, I don't know how to fully verify its existence even if I find it.

Does anyone have a SIMPLE suggestion about this that doesn't involve installing Cygwin or another arcane Windows mechanism?

Can I depend on this new folder naming scheme in some way and size?
MFCNikonImageInfo-VerifyExifTool-07.17.24.JPG

Phil Harvey

If you can run "exiftool -ver" and get back a good version number ("##.##" only, with no warnings), then that would be a good indication that the installation is OK.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

rhenley

Well I'm attempting to verify the file before running it first - I don't want to confuse anyone; so I integrated a FileVersion c++ class I found at CodeProject,

CFileVersionInfo - Retrieving a File's full Version Information Resource
https://www.codeproject.com/articles/1502/cfileversioninfo-retrieving-a-file-s-full-version

that helps pop out this data from the EXE file:

CFileVersionInfo::InternalName = exiftool.exe
CFileVersionInfo::OriginalFileName = exiftool.exe
CFileVersionInfo::ProductVersion = 12.8.7.0
CFileVersionInfo::FileVersion = 12.8.7.0

Otherwise there's not much else from just the basic Windows file that I think I can easily use.

So perhaps with some clarity at some point on the subfolder naming scheme, I might be able to verify it's future fitness with what I can retrieve. I've never yet needed the latest ExifTool versions, as they always worked for me in the basic way I've employed it in the past...



Phil Harvey

Starting with version 12.88 the CFileVersionInfo won't give the ExifTool version number -- it will give the version number of the loader stub by Oliver Betz.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

rhenley

#4
I did see that, but what I think you are saying is that I'm completely out of luck now.

There are other fields available to the VS_FIXEDFILEINFO structure, for example, ProductVersion: which is currently not meaningfully populated in that new tiny sub exe. Perhaps this could be populated now for us, once its no longer considered a test version:

CFileVersionInfo::FileVersion = 1.5
CFileVersionInfo::CompanyName = OliverBetz.de
CFileVersionInfo::FileDescription = ExifTool Perl launcher
CFileVersionInfo::InternalName = ppl-exiftool
CFileVersionInfo::LegalCopyright = Oliver Betz
CFileVersionInfo::OriginalFileName = exiftool.exe
CFileVersionInfo::ProductName = Exiftool
CFileVersionInfo::ProductVersion = universal
CFileVersionInfo::Comments = Test version, use at your own risk

CFileVersionInfo::LegalTrademarks IS Not Populated.
CFileVersionInfo::PrivateBuild IS Not Populated.
CFileVersionInfo::SpecialBuild IS Not Populated.

I still think the old single Windows ExifTool.exe solves this problem handily; are there some instructions so we can put the genie back in the bottle? I've never noticed an issue with ExifTool.exe that this new change is trying to solve, so clearly I haven't been trying hard enough.

Is there clarity on this new subdirectory structure hidden in that long forum post?

StarGeek

"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype