Tweet
My company recent purchased Visual Patch, and I'm setting it up to work with various existing programs that would benefit from an improved patching system.
One problem I've run up against is that some of our older installs put files in place that don't have any Administrator-level privileges - only read (Everyone) and full control (System) - and are owned by System.
One option to fix this would be to add lines to "On Pre Patch" so that takeown and icacls are called to fix up the permissions. The patch file has Requires Administrator in the project settings, so there should be no problem running these utilities.
But...
I did notice that the first time I ran the "unfixed" patch with one of the older install it fails on the first file it attempts to update, then the next time it actually fixes the first file and fails on the second, the time after it fixes the first and second files and fails on the third, etc...
Looking in more detail at what happens when it fails on a file it seems that even though the fix fails after the rollback the file it fails on does have its permissions changed so that Administrators own and have access rights to it. Which suggests to me that something in the standard patch file behaviour is attempting to do the same thing as I am, although on a file-by-file basis.
Could you confirm whether that is the case, and if it is is there anything I can do to make it work more consistently?
One problem I've run up against is that some of our older installs put files in place that don't have any Administrator-level privileges - only read (Everyone) and full control (System) - and are owned by System.
One option to fix this would be to add lines to "On Pre Patch" so that takeown and icacls are called to fix up the permissions. The patch file has Requires Administrator in the project settings, so there should be no problem running these utilities.
But...
I did notice that the first time I ran the "unfixed" patch with one of the older install it fails on the first file it attempts to update, then the next time it actually fixes the first file and fails on the second, the time after it fixes the first and second files and fails on the third, etc...
Looking in more detail at what happens when it fails on a file it seems that even though the fix fails after the rollback the file it fails on does have its permissions changed so that Administrators own and have access rights to it. Which suggests to me that something in the standard patch file behaviour is attempting to do the same thing as I am, although on a file-by-file basis.
Could you confirm whether that is the case, and if it is is there anything I can do to make it work more consistently?