File.Copy versus File.Install ....

[qwerty]

when transfering files from your project to a system, where 99% of the time the files will already exist, which is the better / correct action to use.

i need to be 100% sure that the files are over-written/replaced.

i see the File.Install action has a backup file option, does this rename the existing file allowing a clear route for then transferring the new file in, or does it create a copy of the original file and rename it, meaning that the action must still over-write the original file ?

backing up the file for my use is not realy required, and could result in redundant files being left all over the place, not good !

over-writing the file is the primary goal, and must be achieved regardless of consequences (side effects can be dealt with later !)

Also, i see an option in the File.Install action of "sharedsystem" ... whilst i have a basic understanding of this function, i also have a question .... if the file being replaced/overwritten already has this set to true, what happens to this setting/flag when a File.Copy action replaces the file with another one ?


cheers

[RizlaUK]

have you tried deleting the file 1st, then check if it exists, then copy the file

[qwerty]

manual deletion of the file seems to allow the AMS code to transfer in the new file, i'm in the middle of testing the code to delete the file first, but early indications are that its not being deleted before the transfer takes place.

it's kinda got me baffled at the moment, but pc issues here are causing me to focus on that first

[Lorne]

when transfering files from your project to a system, where 99% of the time the files will already exist, which is the better / correct action to use.

The absolute best in that case would be to use DeltaMAX, especially if the files in question are large. Of course that is a more expensive option and probably overkill in your case.

File.Install with appropriate overwrite settings is what you want. It sounds like you're describing FILE_INSTALL_ALWAYS, but that is not something you should use unless you're sure you want to replace the existing files with your versions -- even if the one the user has is newer.

i need to be 100% sure that the files are over-written/replaced.

The return value from File.Install will tell you whether the operation succeeded. If you really need to be 110% sure, checksum the files after installing them (using CRC32 or MD5).

i see the File.Install action has a backup file option, does this rename the existing file allowing a clear route for then transferring the new file in, or does it create a copy of the original file and rename it, meaning that the action must still over-write the original file ?

The help file is incredibly clear about this. "Any existing file will be renamed to filename.bak. If filename.bak already exists, the file will be renamed to filename.bk1 instead, or filename.bk2, or filename.bk3, etc. The new file will only be installed after the existing one has been backed up."

I'm not sure why you're concerned about the action needing to overwrite the existing file, that's what File.Install is built to do. You don't need to delete the file first -- using FILE_INSTALL_ALWAYS will achieve the same effect.

over-writing the file is the primary goal, and must be achieved regardless of consequences (side effects can be dealt with later !)

Be very careful. If any of the files you're installing are system files (DLLs and such) I would strongly caution you not to do this.

Also, i see an option in the File.Install action of "sharedsystem" ... whilst i have a basic understanding of this function, i also have a question .... if the file being replaced/overwritten already has this set to true, what happens to this setting/flag when a File.Copy action replaces the file with another one ?

I believe in that case the reference count gets incremented.

[qwerty]

ok, firstly , thank you for the well laid out reply answering my questions.

Yes, you are correct the proceedure i was describing and intending to use was FILE_INSTALL_ALWAYS

I iwll look into the return value thing for checking, that could be what i need.

where you say this

The help file is incredibly clear about this. "Any existing file will be renamed to filename.bak. If filename.bak already exists, the file will be renamed to filename.bk1 instead, or filename.bk2, or filename.bk3, etc. The new file will only be installed after the existing one has been backed up."

ok, so as i understand that then the original file is renamed and then there should be no issues encountered on transferring the new file in,


The reason for these strange questions is that i have hit a problem relating to file transferring, and on some systems it works and others it doesnt, this appears not to be an error in the script, more a system block on over-writing the file especially if the orignal is newer, Hence the reason i want the original file out of the way. My bet is that windows vista is causing issues becasue of it's love of playing god

[Lorne]

Be careful. The OS usually has good reasons to protect its files.

What kinds of files are you trying to replace?

[qwerty]

mixed, exe,dll,sys (but not a shared or M$ sys files) and a couple ico files.

it seems i was doing something wrong, becasue even with the rename thing set to on it fails to even rename them, i've gone back to file.copy, and have tried to build an error check into the routine.

when i get more time i will revisit this issue, because it was behaving just as if the destination was wrong, and thus couldnt find the files, very strange, as its the same variable used to supply the destination path for the fil.copy command as it was for the file.install one

[Lorne]

Are you sure it's the same? (Could be a typo.) Is anything else different as well? Check the contents of that variable in both cases using a Dialog.Message action (or Debug.Print or something).

[qwerty]

if i wasnt using so much copy and paste i would be more inclined to believe that, with my typing abilities !

but as i modified the File.Install to File.Copy by over typing Install with Copy and changed the parameters (true flase etc) at the end by copying the first one i changed manually, and all seems to work, i dont think it's a typo on the file path or name

[Lorne]

Check the contents of that variable in both cases using a Dialog.Message action (or Debug.Print or something).