MoveFile Table & MoveFiles Action

Created: 10 Jul 2012 | Updated: 09 Oct 2012 | 14 comments

wancsho

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:

Endpoint Management, Wise Packaging

Comments RSS Feed

Comments 14 Comments • Jump to latest comment

Mistral Partner Accredited

MoveFile Table & MoveFiles Action - Comment:10 Jul 2012 : Link

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

MoveFile Table & MoveFiles Action - Comment:11 Jul 2012 : Link

@Mistral:

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 Trusted Advisor

MoveFile Table & MoveFiles Action - Comment:11 Jul 2012 : Link

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:

FileKey

Primary key that uniquely identifies a particular MoveFile record.

Component_

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.

SourceName

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 ?).

DestName

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.

SourceFolder

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).

DestFolder

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

MoveFile Table & MoveFiles Action - Comment:11 Jul 2012 : Link

@EdT:

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

Attachment	Size
Intall.zip	18.22 KB

Mistral Partner Accredited

MoveFile Table & MoveFiles Action - Comment:11 Jul 2012 : Link

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

MoveFile is not designed to copy/move installed files.

EdT Trusted Advisor

MoveFile Table & MoveFiles Action - Comment:11 Jul 2012 : Link

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

MoveFile Table & MoveFiles Action - Comment:18 Jul 2012 : Link

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)

http://msiworld.blogspot.com/

Mistral Partner Accredited

MoveFile Table & MoveFiles Action - Comment:18 Jul 2012 : Link

We are using it successfully for years.

EdT Trusted Advisor

MoveFile Table & MoveFiles Action - Comment:19 Jul 2012 : Link

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.

i.e.

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

MoveFile Table & MoveFiles Action - Comment:19 Jul 2012 : Link

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

Cheers,

Piyush

Piyush Nasa Altiris Certified Professional (ACP)

http://msiworld.blogspot.com/

Mistral Partner Accredited

MoveFile Table & MoveFiles Action - Comment:11 Jul 2012 : Link

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 Trusted Advisor

MoveFile Table & MoveFiles Action - Comment:12 Jul 2012 : Link

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

MoveFile Table & MoveFiles Action - Comment:09 Oct 2012 : Link

#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.

-wancsho

SOLUTION

Mistral Partner Accredited

MoveFile Table & MoveFiles Action - Comment:09 Oct 2012 : Link

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

MoveFile Table & MoveFiles Action

Comments 14 Comments • Jump to latest comment

Would you like to reply?

Links