FileGetVersion() returns outdated info - RESOLVED

[tremolux66]

I found a very old AutoIt script for obtaining file version information (Properties > Details items like the version string, product name, copyright, etc.). It didn't work very well, so I rewrote it after I discovered FileGetVersion().

The problem is that FileGetVersion() is returning outdated information that seems to belong to an old version of the file, long after the file has been deleted and recreated. Windows Explorer, on the other hand, shows up-to-date version info in the Properties > Details tab because (I think) it's accessing the cached file metadata and/or the latest version of the file. This looks similar to the Windows behavior in which (e.g.) the modification time for a previous incarnation of a file is still displayed by dir even after the file has been deleted and recreated. The timestamp is updated eventually, but in my case "eventually" is approaching infinity.

Is there a way in AutoIt to force retrieval of the latest file version properties? Failing that, is there some external method (like a command or admin setting) that can force Windows to return the latest version info when requested by a program?

Edited March 12, 2016 by tremolux66
Problem resolved

[Jos]

Did you check whether the file also exists in: %localappdata%\VirtualStore ?

Jos

[tremolux66]

 

10 minutes ago, Jos said:

Did you check whether the file also exists in: %localappdata%\VirtualStore ?

Jos

No; not sure I understand the significance of that.

On the machine I'm developing & testing on, there are only a few folders and files in the %localappdata%\VirtualStore directory tree, and their modification times are a year or more ago. They're mostly from C:\Program Files and C:\Program Files (x86); nothing to do with the directories I'm working in (with my script's .exe and the files it's looking at).

[Jos]

The reason for the question was whether it is finding a different version of the file in the virtual store. That is the only reason I can think of why this could happen.

Another one is when checking files in certain directories like c:\windows\system32  in x64 or x86 mode can return different results.

Jos

 

[tremolux66]

Ah. Nope, my files aren't there.

Windows Explorer (Win 7 Enterprise) can locate old versions of the files I'm testing with and says the location is "Restore point". When I look at the Details tab on the previous version of the file, it's yet another version from what my FileGetVersion() script is reporting, e.g.,

• Explorer reports file version = 2016.1.20.1 (correct)
• My script reports file version = 2016.1.8.3
• Explorer reports previous version's file version = 2016.1.8.4

The files I'm dumping the version info for are mostly AutoIt script .exe files; I use /fileversion Year.Month.Day.Iteration# when building my production code. (I also use /productname, /productversion, /legalcopyright, etc.) The build script deletes all the .exe files from the target directory before running Aut2Exe.

Edited January 21, 2016 by tremolux66
Reformat some of the text for readability (font).

[MilesAhead]

I am not sure what is happening.  But ShadowExplorer may show you how many old copies you have to give some clue.  It is freeware.

 

[tremolux66]

5 hours ago, MilesAhead said:

I am not sure what is happening.  But ShadowExplorer may show you how many old copies you have to give some clue.  It is freeware.

 

Thanks - I'll give that a look.

[tremolux66]

RESOLUTION: I got a new computer. It looks like the OS on my old computer must have been corrupted (somehow). I was seeing a lot of strange behavior w.r.t. an external CD/DVD/BD writer like: 4 drive letters instead of 1, write failures, a drive letter disappeared, regedit crashed when I was investigating the drive-letter issue (trying to back up the Registry), incredibly long load times for optical media, etc. Plus the weird problem described here with out-of-date file information returned by FileGetVersion().

I was issued a new computer, with a fresh OS image, and when I plugged in the optical writer it worked perfectly: 1 drive letter, no write errors, fast load times. It eventually occurred to me to retest my file info utility, and it worked perfectly (so far).

Go figure.