File in use causing patch to fail

[NickSills]

Hi All

I've noticed this log file entry for a customers failed patch:

Error Deleting original file (5): C:\Program Files\Macrium\Reflect\RefSched.exe (106)

This caused the patch to fail. I know that the (5) error code is 'Access Denied' but why should this cause the patch to fail? The patch was run by the machine Administrator and previous patches hadn't had problems with this file. This file is definitely in use and always will be during the patch process. I thought that files that couldn't be access were patched on the next reboot.

Any ideas?

Thanks

[Lorne]

Couple questions:

1. Is that file marked as a key file?
2. Is it a legacy file? (A file that existed in a previous version, but does not exist in the version you are patching to.)

[NickSills]

Hi

I believe it was a key file at the time for both the existing and new version. The existing version was successfully found:

[10/07/2007 12:42:18] Success Located installed version 4.1.1895: C:\Program Files\Macrium\Reflect\

This hasn't caused a problem before. There may have been multiple occurrences of this file running from different accounts, but I can't see why that would make a difference.

[NickSills]

[EDIT]

Sorry about this but our patch projects have been changed lately to overcome some problems; it definitely wasn't a key file.

[Lorne]

Do you know whether the whole file was included for that file, or a binary difference was to be performed?

[NickSills]

I believe it was a 'forced' install, therefore the whole file would have been included.

[Lorne]

Hmmm, if it was a forced install it should have been set to be replaced on the next reboot then.

Could it be a permissions issue? (It might not have to do with the file being in use after all.)

[NickSills]

No, the file was installed by the same user who ran the patch, and that user was an administrator. Am I corect in assuming that unless the file is a key file then 'file in use' shouldn't cause the patch to fail? Because that's what seems to have happened... Multiple users had this file open, but I didn't think this was an issue.

[Lorne]

No, the file was installed by the same user who ran the patch, and that user was an administrator. Am I corect in assuming that unless the file is a key file then 'file in use' shouldn't cause the patch to fail? Because that's what seems to have happened... Multiple users had this file open, but I didn't think this was an issue.

If the file wasn't deleted because it is in use, I would expect it to generate error 32 (ERROR_SHARING_VIOLATION), not error 5 (ERROR_ACCESS_DENIED).

I looked at the source code and if the file deletion reports ERROR_SHARING_VIOLATION then it will continue, but if the file deletion reports anything else (including ERROR_ACCESS_DENIED) it is considered a fatal error.

It might be worth checking the permissions on the file, just in case.

According to MSDN, the patch must be in the context of a user who belongs to the Administrator group or the LocalSystem account.

I suspect that write access to the following registry key would be required as well:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\PendingFileRenameOperations

One possible workaround might be to use the g_OnFileProcessed function in Visual Patch (see Miscellaneous > Hidden Functions in the help file), and call Application.SetLastError() to override the error for that file.

[NickSills]

Thanks for that information! I'll look into it and report back.