Recently Browsing 0 members
No registered users viewing this page.
AppendVersion_x64 is a simple program intended to expedite the systematic renaming of executable
installation files, compressed installation files and Start Menu links that point to installed executable
In this discussion, 'target executable file' can refer to an uncompressed installation executable, or to the
compressed installation executable file inside a packaged compressed file (zip, 7z, rar or tar), or to the
executable file that a Start Menu link points to. A 'rename target' can refer, again, to an uncompressed
installation executable file, or to the compressed file containing a packaged target executable file, or to
a Start Menu link pointing to a target executable file.
There are four scenarios for AppendVersion processing:
An installation executable file is renamed and appended with that target executable file's own
file version number.
A compressed installation file (zip, 7z, tar, or rar) is renamed and appended with its compressed
target executable file's own file version number.
A Start Menu link pointing to its target executable file is renamed and appended with that
target executable file's own version number.
A folder is selected containing any assorted collection of rename target types.
Having an archived program installation file renamed with its target executable file's file properties
version number appended to the installation file's name, in a systematic format, aids in quickly
determining whether or not you have the latest version installed.
Having all the Start Menu program links (rename targets) appended with their target executable file's
version numbers quickly aids in determining whether or not you have the most recent published
upgrade or update of that program installed. Hovering your mouse over a Start Menu link will
conveniently display the target executable file's version number.
Start Menu links exist in two system folders:
@ProgramsDir (%appdata%\Microsoft\Windows\Start Menu\Programs)
@ProgramsCommonDir (%programdata%%\Microsoft\Windows\Start Menu\Programs)
Renaming Start Menu links in these two folders require Administrator privilege. You can either compile
this AppendVersion.au3 script with the #RequireAdmin macro at the top of the script, or go to the
compiled executable 'AppendVersion_x64.exe' file's Properties Compatibility tab and check 'Run this
program as an administrator'.
AppendVersion can also receive full file path argument parameters via Run or the Windows terminal.
This allows for processing files from different directory locations in one AppendVersion session.
AppendVersion is initiated via a Windows SendTo 'AppendVersion' link. Running the compiled
executable 'AppendVersion_X64.exe' once will auto-create an 'AppendVersion' link in the SendTo
subfolder if the SendTo link does not exist and will also create a default Settings.ini file in the @ScriptDir
folder if the Settings.ini file does not exist. The Settings.ini file maintains basenames and other
configuration data that AppendVersion requires.
Icon @ScripDir subfolder location directive for compiling AppendVersion_x64.au3 is:
To use AppendVersion, in Windows Explorer select one or more rename target files, rename target links
and any folders containing rename target files or links, then select the SendTo 'AppendVersion' link.
You can also right-click on a Start Menu link and select Open Location:
After Windows Explorer opens, right-click on the highlighted rename target link and then select
'AppendVersion' from the SendTo menu.
You can also process Start menu rename target links enmasse in succession by selecting one of the two
Programs folders where Windows maintains most all the Start Menu links:
Select one of the two Programs folders and then select 'AppendVersion' from the SendTo menu
You can process both Programs folders in one session by running the compiled executable
'AppendVersion Start Menu Links_x64.exe'.
The script maintains processed file identification data in the Settings.ini [BaseNames] section. This
section is used in identifying new updated versions of earlier files previously processed by
AppendVersion. This file identification data (key basenames and fingerprint value) is used to compare
and systematically rename later matching updated versions of the identified file.
'Basename(s)' is one or two substrings in the installation file that usually does not change in the rename
target file name from one file version to the next.
Except for file size and file/product version properties, which can change with every new file version, the
remaining available target file properties are concatenated together to create a target file properties
'fingerprint'. The fingerprint consists of file properties that usually will not change from one target file
version to the next, i.e., 'File Description', 'Product Name', 'Copyright', 'Language', 'Original File name',
'Legal Trademarks', 'Company Name' and 'DefaultLangCodePage'.
The basename(s) and fingerprint together constitute the 'identification' of a candidate file. This ID is
used to identify later downloaded versions of the file that can be automatically renamed without user
If the target executable file's properties does not have a file version number, the file's product version
number will be used instead in the version appending and renaming of the file.
If the target executable has neither a file version nor product version number, the user will be prompted
to enter the published file version number acquired from the provider's web site.
Both the basename(s) and version numbers will be used for the renaming of the file.
If the rename target file is in a popular compressed format, i.e., (*.zip, *.7z, *.rar, and *.tar), the script
will use PeaZip-portable to decompress the zipped file into a temporary folder (@ScripDir & "\UnZip")
and then prompt the user to select the target executable file with file properties used in the rename
The freeware PeaZip portable can be downloaded from:
Unpack PeaZip portable into the @ScripDir & "\peazip" subfolder.
Once the target executable file properties are read from the target executable, the user will be
prompted to configure the basename(s) from the rename target file name, unless an identification
already exists in Settings.ini, in which case the rename target file will automatically be renamed by
AppendVersion. The process is not always fully automatic. If the target executable file has neither a file
nor product version in its file properties, the user will be prompted to manually enter the published file
Process example, the target file for renaming is:
Righ-click on the file. Select 'AppedVersion' from the SendTo submenu.
The script, recognizing the rename target file as a compressed file (*.zip, *.7z, *.tar, and *.rar), will decompress
the rename target file into a temporarily created @ScriptDir & '\UnZip' folder.
Then, the user will then be prompted to select from the folder or subfolder containing the target
executable file from which the file properties will be read:
Once the target executable file is selected and opened, the script will prompt the user to create one or
two basename(s) from the rename target zip file's name.
Base name(s) are created from the rename target zip file name (without extension):
Examples, 'FreeFileSync_' , '[Donation_Edition]' and '_Windows_Portable'.
Base names must be separate substrings in the rename target zip file's name.
The user can choose to use just one or two base names for file identification.
The user can also choose to use the entirety of the original rename target zip file name:
as a base name in renaming later versions of FreeFileSync. This may not be advisable with this base name, since later versions of this rename target
file name will not have version '11.14' in the name, but this naming convention is an option.
In this example, I will use the 'FreeFileSync_" and '[Donation_Edition]' substrings as base names, since
these are file name structures that are unique to the file name and will probably not change in later
published file version names.
The file properties fingerprint collected from the FreeFileSync.exe executable is:
To use two base names for later automatic file version identification, the base names must be
separated with a colon ':', i.e., 'FreeFileSync_:[Donation_Edition]'.
If a later file version of a candidate rename target file's name contains both of these substrings and
has the same target executable file properties 'fingerprint', the script will automatically identify and
rename the later-versioned file's name.
The combined file identification of [Key] base names + [Value] fingerprint is:
This identification is stored in the Settings.ini file under the [BaseNames] section.
When a new version of FreeFileSync_XX.XX_[Donation_Edition]_Windows_Portable.zip is processed by
AppendVersion, if an entry in Settings.ini [BaseNames] section can match the rename target's file name
and also match the candidate target executable's fingerprint, the script will use this to automatically rename the zip file.
Finally, the rename target file is then renamed with the base name(s) and with one of three version
prefixes to the version number:
" - fver_ "; for files with a properties file version number (preferred default)
" - pver_ "; for files without file version numbers but with product version numbers(fallback)
" - uver_ "; for files with neither file nor product numbers. User manually entered published file version number.
NOTE: These version format prefixes can be changed in Settings.ini [QuotedPrefix] section to meet your
prefix format preferences. The [QuotedPrefix] section value entries must be quoted.
In this example, FreeFileSync.exe contains a properties file version number of 188.8.131.52
The resultant AppendVersion renamed file is:
FreeFileSync_[Donation_Edition] - fver_ 184.108.40.206.zip
This systematic approach works well with most file names, but files with short file names such as 'a.exe'
and having no finger-printable file properties are problematic. In such case, perhaps renaming the
downloaded file with a longer, unique name before running this script on it is preferrable, although
renaming the file before processing it with AppendVersion circumvents the purpose of the script. This
would not be an issue if software creators would always include full file properties in their file
Settings.ini add2.ico ReadMe.pdf
AppendVersion Start Menu Links.au3 AppendVersion.au3
I'm not sure if its possible that I'm trying to achieve, I've looked into https://www.autoitscript.com/autoit3/scite/docs/SciTE4AutoIt3/AutoIt3Wrapper.html and such resources for help, but I cant really find the answer to my question.
So upon compiling the script in SciTE, the exe file is given a Description under file Properties>Details. I understand, that one can enter info manually there and it can even implement the version automatically with each compilation.
What I'm trying to achieve is to somehow include the "@ScriptName" in the Details>File Description Field. But as I see no variable can be taken after "#" in this case.
Do You think its achievable? (Win 10)
Much obliged for taking time on reading this.
I had a hdd that crashed and upon receiving a replacement from my online backup, the Date Created, Date Modified, and Date Accessed were set to the date of the copy, and not the actual creation date. I did find that for my .jpgs, under Details, there is a Date Taken field that has the correct data. Can AutoIt be used to find the Date Taken, and then Set the Date Created to the value in Date Taken? I've never seen any of these kinds of functions in AutoIt. Thanks!
This is a modification of a script that was originally posted back in 2006, that was itself a modification of a script in the same thread, which was a modification of another script linked in that thread. All credits remain in the header as to who contributed to this.
The only credit I take in this script is modifying parts of it to:
1.make it a bit faster, by removing a ReDim that was inside a loop
2.add support for OSs other than XP because of the number of file properties returned
3.add support for the future if the number of file properties returned changes again with future versions of Windows
Please take note, this script will only work if you know the name of the property you're trying to retrieve. These properties are dependent upon the OS version, the OS language, and the file's properties. This function does not take any of these things into account, if you want to use this and make it OS neutral, you'll have to do that in your script, because it doesn't get done in here. Fortunately, if you access this function and leave the parameter $FGP_Property blank, it will return an array of all the properties that Windows knows about, and in the language that Windows is running in.
Windows XP only returns 38 properties, Windows 7 returns 288, Windows 8 returns 290. The same properties can have different names depending on which OS you're using this with.
Update Sept. 6, 2017
Changed the code slightly to make sure the return includes all properties, the last update cut off some of the properties at the end, and increased the $iPropertyCount to 500 (from 300) because of Windows 10 file property count increase.
I have tweaked this function again, a small update.
Added a new parameter to the function, $iPropertyCount, with a default setting of 300. This parameter was previously hard coded inside the function, now you are able to adjust it to the setting you desire/require. This value is used to determine how many file properties will be searched for the value passed in $FGP_PROPERTY, or the maximum amount of properties that will be returned in the array if $FGP_PROPERTY is a blank string. The $FGP_PROPERTY parameter will now accept the Default keyword in place of a blank string, which tells the function to return an array of all known properties, up to the setting of $iPropertyCount. Update: Feb-11-2013
I have updated this function again.
Now it has a single point of return, except for error exceptions, instead of multiple places that it returned from previously. I've renamed the variables used so that they'll be less chance of a name collision with someone's script. Fixed a small bug that added a blank line to the end of the array returned when getting all properties. Changed the return value on an error from 0 to an empty string. NOTE: This is a repost of a thread I had already posted last year. I went looking for it today to update the code in it, and found that it had disappeared.
#include <File.au3> ; only used for the example script, not needed for the UDF #include <Array.au3> ; only used for the example script, not needed for the UDF #include <Constants.au3> ; only used for the MsgBox, not needed for the UDF $sFolder = FileSelectFolder("Select a folder to scan", "") $sFolder &= "" $aFiles = _FileListToArray($sFolder, "*.exe") For $I = 1 To $aFiles $aDetails = _FileGetProperty($sFolder & "\" & $aFiles[$I]) ; Returns an array with all properties of the file _ArrayDisplay($aDetails) Next Global $sDetails = _FileGetProperty($sFolder & "\" & $aFiles[$aFiles], "date modified") MsgBox($MB_SYSTEMMODAL, "Date Modified", $sDetails) ;=============================================================================== ; Function Name.....: _FileGetProperty ; Description.......: Returns a property or all properties for a file. ; Version...........: 1.0.2 ; Change Date.......: 05-16-2012 ; AutoIt Version....: 220.127.116.11+ ; Parameter(s)......: $FGP_Path - String containing the file path to return the property from. ; $FGP_PROPERTY - [optional] String containing the name of the property to return. (default = "") ; $iPropertyCount - [optional] The number of properties to search through for $FGP_PROPERTY, or the number of items ; returned in the array if $FGP_PROPERTY is blank. (default = 300) ; Requirements(s)...: None ; Return Value(s)...: Success: Returns a string containing the property value. ; If $FGP_PROPERTY is blank, a two-dimensional array is returned: ; $av_array = Number of properties. ; $av_array = 1st property name. ; $as_array = 1st property value. ; $av_array[n] = nth property name. ; $as_array[n] = nth property value. ; Failure: Returns an empty string and sets @error to: ; 1 = The folder $FGP_Path does not exist. ; 2 = The property $FGP_PROPERTY does not exist or the array could not be created. ; 3 = Unable to create the "Shell.Application" object $objShell. ; Author(s).........: - Simucal <Simucal@gmail.com> ; - Modified by: Sean Hart <firstname.lastname@example.org> ; - Modified by: teh_hahn <sPiTsHiT@gmx.de> ; - Modified by: BrewManNH ; URL...............: http://www.autoitscript.com/forum/topic/34732-udf-getfileproperty/page__view__findpost__p__557571 ; Note(s)...........: Modified the script that teh_hahn posted at the above link to include the properties that ; Vista and Win 7 include that Windows XP doesn't. Also removed the ReDims for the $av_ret array and ; replaced it with a single ReDim after it has found all the properties, this should speed things up. ; I further updated the code so there's a single point of return except for any errors encountered. ; $iPropertyCount is now a function parameter instead of being hardcoded in the function itself. ;=============================================================================== Func _FileGetProperty($FGP_Path, $FGP_PROPERTY = "", $iPropertyCount = 500) If $FGP_PROPERTY = Default Then $FGP_PROPERTY = "" $FGP_Path = StringRegExpReplace($FGP_Path, '["'']', "") ; strip the quotes, if any from the incoming string If Not FileExists($FGP_Path) Then Return SetError(1, 0, "") ; path not found Local Const $objShell = ObjCreate("Shell.Application") If @error Then Return SetError(3, 0, "") Local Const $FGP_File = StringTrimLeft($FGP_Path, StringInStr($FGP_Path, "\", 0, -1)) Local Const $FGP_Dir = StringTrimRight($FGP_Path, StringLen($FGP_File) + 1) Local Const $objFolder = $objShell.NameSpace($FGP_Dir) Local Const $objFolderItem = $objFolder.Parsename($FGP_File) Local $Return = "", $iError = 0 If $FGP_PROPERTY Then For $I = 0 To $iPropertyCount If $objFolder.GetDetailsOf($objFolder.Items, $I) = $FGP_PROPERTY Then $Return = $objFolder.GetDetailsOf($objFolderItem, $I) EndIf Next If $Return = "" Then $iError = 2 EndIf Else Local $av_ret[$iPropertyCount + 1] = [] For $I = 1 To $iPropertyCount If $objFolder.GetDetailsOf($objFolder.Items, $I) Then $av_ret[$I] = $objFolder.GetDetailsOf($objFolder.Items, $I - 1) $av_ret[$I] = $objFolder.GetDetailsOf($objFolderItem, $I - 1) ;~ $av_ret += 1 $av_ret = $I EndIf Next ReDim $av_ret[$av_ret + 1] If Not $av_ret Then $iError = 2 $av_ret = $Return Else $Return = $av_ret EndIf EndIf Return SetError($iError, 0, $Return) EndFunc ;==>_FileGetProperty Warning, old code below.