Video Screencast Help

MoveFile Table & MoveFiles Action

Created: 10 Jul 2012 • Updated: 09 Oct 2012 | 14 comments
This issue has been solved. See solution.

Hello Experts!

I am trying to copy and move files from source loc to destination using MoveFile table but the process which i follow to do so is unsuccessful, so kindly suggest.

Task: Copying file abc.htm from Program Files\ABC Folder to Program Files\ABC\Copy.

Procees followed:

->Creating a row in MoveFile table with the following details:

FileKey: Move1

Component_: MoveFile (Created a empty component)

SourceName: abc.htm

DestName: (The field was left blank)

SourceFolder: INSTALLDIR1 (which gets resolved to Program Files\ABC)

DestFolder: Copy (which gets resolved to Program Files\ABC\Copy)

Options: 0 or 1

Position of standard action"MoveFiles": Not changed

** INSTALLDIR1 and Copy are the directory names fetched from directory table.

Even relocated the position of MoveFiles standard action(placing it after InstallFiles) couldnt solved the issue.

**Note: The Task needs to achieved using MoveFile table and not using any custom action.

Thanks- wancsho

Discussion Filed Under:

Comments 14 CommentsJump to latest comment

Mistral's picture

Did you assign the Component to a feature?

MoveFiles is used for files that do already exist on the target machine ... this is the case?

If you want to copy installed files, i recommend using the DuplicateFile table.

wancsho's picture


Yes, the component is part of the feature.

The abc.htm is part of the msi, which means i need to copy the file installed by the MSI.

Thanks- wancsho

EdT's picture

Does the target "Copy" folder exist? If not, you need to ensure you add it to the CreateFolder list.

Looking at the MoveFile table definition:


Primary key that uniquely identifies a particular MoveFile record.


External key into the Component table. If the component referenced by this key is not selected for installation or removal, then no action is taken on this MoveFile entry.


This column contains the localizable name of the source files to be moved or copied. This column may be left blank. See the description of the SourceFolder column. This field must contain a long file name and may contain wildcard characters (* and ?).


This column contains the localizable name to be given to the original file after it is moved or copied. If this field is blank, then the destination file is given the same name as the source file.


This column contains the name of a property having a value that resolves to the full path to the source directory. If the SourceName column is left blank, then the property named in the SourceFolder column is assumed to contain the full path to the source file itself (including the file name).


The name of a property whose value resolves to the full path to the destination directory.

I have highlighted the points you need to check. Create a verbose installation log and check that the PROPERTY values you are specifying in the source and destination columns actually exist. The log shows property values at different points in the install. As a test, you could hard code property values into the property table and see if this makes a difference. Also, make sure that the component you are using is actually associated with a feature that is getting installed, and check what key path has been set for this component. If the component is not getting installed for ANY reason, then the movefiles action will not happen.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

wancsho's picture


Checked again and still not working. Even checked with putting hardcoded enteries for DestFolder and SourceFolder:( Find the attached .log file of the installation.

Thanks- wancsho

AttachmentSize 18.22 KB
Mistral's picture

Why you are not using the DuplicateFile table? It was made for this.

MoveFile is not designed to copy/move installed files.

EdT's picture

If you think about it, Mistral is absolutely right. The MoveFiles action returns 0 which means it completed successfully, but of course there is nothing for it to do.

When InstallInitialize is reached, Windows Installer evaluates each action to see if it is immediate or deferred, and it executes immediate actions immediately, but deferred actions are evaluated and added to the script queue. The MoveFiles action, which is deferred, is evaluated and the files to be moved are checked. In your case the files are not present (as they have not been installed yet) so the action has nothing to do. When InstallFinalize is reached, the deferred script queue is executed in sequence and system changes are made. Since there was no file to be moved/copied, the action does not need to do anything, and this is what you are seeing.  The experience with hard coding the paths just confirms that the MoveFiles action is not the right one for the job.

The DuplicateFile table exists specifically to allow you to install the same file into two or more different locations - it was designed to make MSI files more efficient and avoid duplication of component contents.

The only caveat is that if the "primary" file instance is not installed then the duplicates are not installed either, so you need to make sure that the component holding the primary file is always installed.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

piyushnasa's picture

I don't know but I have never been able to use the Duplicate file. I know the concepts, but I was trying to implement in one of the packages and it does not copy the file.

Piyush Nasa Altiris Certified Professional (ACP)

Mistral's picture

We are using it successfully for years.

EdT's picture

Would need to see how you are implementing it. Like Mistral, I have been using it for years successfully.

You need to remember that the duplicate file does not get installed if the "master" file is not installed for any reason. The target folder needs to exist also.

I documented it as part of a self healing process where the source files are installed under the app's program files folder and the destination is the user profile, and the files are automatically copied to the user profile when an advertised entry point is triggered.  I have found the text of the instructions and these are reproduced below in case you want to give it a try:

For those of you whom have read my first post on HKCU registry healing. 
Here is the next step which will enable you to heal files as well as 
HKCU keys. 
If you have followed the first step which creates a feature structure 
in the following manner. 
HKCU - (Current User Feature) 
- Complete (Remainder of application) 
Your HKCU feature will only contain CurrentUser components or 
components which contain registry entries which are destined for
the HKCU registry hive. 
The complete feature will contain the main application including all
"program files\%appname%" and HKLM entries. The reason for this is 
explained in the first Current User healing guide. 
Now to make full advantage of this method of healing often you are 
required to put files into the users profile directories such as 
"c:\documents and settings\%username%\application data" or similar 
folders such as "my documents" etc. 
This is a way to allow you to heal this folder for each user, without
requiring to step outside of the msi to maintain the healing process.
Therefore no need for active setup or other methods, this is all fully
self contained within the msi. 
To understand how this works its important to know how the duplicate 
file table works within the msi. The duplicate file table is used 
to reduce the size of an msi and increase performance by not 
replicating files inside the msi. For example if you have a file 
in your package in the following locations which is identical the
default behavious of msi is to not add this file again. 
c:\program files\%appname%\folder1\file1.txt 
c:\program files\%appname%\folder2\file1.txt 
here we have 2 files with the same name and structure. Under normal
conditions the msi would recognise this file is the same and it 
would make an entry in the duplicate file table. If we assume in the
above example .\folder1\file1.txt was the first file to be placed into
this msi it would then show in the file table as a normal file as 
expected. However when we add .\folder2\file1.txt what you would expect
is that another entry would be added to the file table as per the 
previous entry. However if the msi recognises the file is identical 
it does not use another entry in the file table instead it creates an 
entry in the duplicate file table. The duplicate file table then makes 
a pointer back to the first location where this file was installed to. 
Therefore .\folder1\file1.txt was the first entry so instead of 
.\folder2\file1.txt being added again it uses the duplicate file table
and makes a reference back to the install directory of the first 
file1.txt. In this case "c:\program files\folder1\file1.txt". 
What this means is that .\folder2\file1.txt does not get installed 
from the cabs of the msi but installed directly from its first 
install directory. 
In other words the .\folder1\file1.txt is copied to .\folder2\file1.txt. 
Hopefully that hasn't confused you too much :-). 
The next step is to do this. 
As with the first guide I wrote you create your feature structure with
the HKCU feature at the top of the tree. You then do this. 
HKCU - (CurrentUser components) 
- Complete Feature (remainder of app) 
We now create a folder under [INSTALLDIR] or "C:\program files\%appname%\_user"
or whatever naming convention you like. I like "_user". 
We then add any files into this folder that we would like to be 
delivered to the users profile. For example if you want 
"C:\documents and settings\%username%\application data\file1.txt" then we
would create the following. 
"c:\program files\%appname%\_user\application data\file1.txt" and 
so on. 
For each file that you want to be healed by this method you need to 
have the same file delivered to "C:\program files\%appname%\_user" 
Once you have completed this you then add those same files again into
the normal locations of "c:\documents and settings\%username%" however
this time the duplicate file table comes into play!!!. These files that
are being added for the 2nd time are recognised as already being in the
package and the follow the same rules as above with the duplicate file
table. Therefore they have entries in the duplicate file table instead
of the file table. This also means that these files are healed from the
local machine and not from the MSI. 
This has a few benefits, one is that you do not require the MSI to be
present during healing time. So if you haven't got a connected source
it gets around that issue (mind you I am not saying don't use 
[SourceList]) Its just a workaround if needed. 
Now the final touch is to move all the components that were created 
during this step into the HKCU feature, my preference is to put the 
files in the same component as the HKCU registry entries that were 
created via the first guide. This is because the duplicate file 
components do not have keypaths therefore technically dont have a 
healing reference. Hence putting them in the HKCU component ensures
a heal for each new user. 
Therefore you would have the following configuration. 
HKCU - CurrentUser (component) 
- Contains = HKCU registry 
- = Duplicate File infomation 
- Complete 
- All other components 
This means that HKCU is at the top of the tree and contains both the
CurrentUser components containing the HKCU registry entries. 
And the duplicate file table entries are in the same component. 
The complete feature just contains the main application. 
Putting it all together. 
When you run the application and a user has not logged on before the
HKCU entries are not present. Therefore when advertising is run from
the complete feature the Complete feature is checked, all component 
keypaths are checked if something is missing from the Complete feature
it is healed in its entirety. As per normal the MSI will then step up
the tree and run the checking functionality as per before. However in
this instance as the advertising is downlevel from the HKCU feature 
the healing process changes slightly and steps into what is classed 
as Component level healing. Therefore if a keypath is missing only 
the single component is healed and not the entire feature. This is 
the reason why I like to put the duplicate file info into the same 
component as the HKCU registry entries. 
If you delete the HKCU entries when advertising is next run it will 
put back both the HKCU entries and the files as they are in the same
component as the HKCU keys. 

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

piyushnasa's picture

Thank you so much.. I will try this and let you know.



Piyush Nasa Altiris Certified Professional (ACP)

Mistral's picture

I might be wrong, but i think the decision if a file will be moved, or copied is even taken between CostInitialize and CostFinalize.

EdT's picture

You may well be right - the costing process has to establish whether the target volume(s) have sufficient space to allow the installation so it needs to work out what will actually need installing or moving around.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

wancsho's picture

#Finally MoveFile table can be used to copy file#

Tried once and It worked but tried again it didnt and now after a long time it worked again:

MoveFileTable: Copying file from current directory(where MSI file is present) to INSTALLDIR.

1. Added the standard action ResolveSource after CostFinalize in UI and Immediate mode.

2. Placed the the file Abb.vbs in current directory along with the MSI.

3. Added the following entry in MoveFile table(image below).

4. Saved the MSI and it worked.


Mistral's picture

What does the validation say when you change the order of this built in actions?