Return to Answer

My feedback

Thanks @amon and @gapsf for the provided solutions. My experience so far is:

(1) Patching Algorithm

BsDiff 4, a nice algorithm originally written in C++ and probably already ported to C#, can be used for implementing a deployment system which finds binary differences for individual existing modified files, no matter what the file extension is. For other files which shouldn't exist either before or after the patch, simply adding them or removing them accordingly is enough. Everything can be packed into a compressed file and manipulated with your own patch installation system. Easy.

To make sure the patch system creates the new binary directory perfectly, a list with hashes of all files expected to be modified by the patch, and another list with hashes of all files expected after the patch has completed should be good enough for the validation of the patching process.

(2) Deployment

In case of any issues with your patching (for whatever reason you may possibly imagine), my preferred approach so far is first to construct the new binary directory separately. After it is consistently generated, there are two possible approaches:

(2a) Move the old binary directory to a fallback backup folder. Afterwards move the newly constructed binary directory to the official location. But you may not be able to guarantee that no one is using a given binary (e.g. from another computer in the network), which could block directory move operations.

OR

(2b) Alternatively, use a junction link as your official binary directory. It points to the current binary directory (e.g. a directory location out of sight of the user). If the junction link points to the 'bin_v1.0' binary directory, it can be modified during the deployment for pointing to the 'bin_v2.0' binary directory through an one-shot command line, using the tool ln.exe. This prevents any binary being executed or any open file in your binary directory from blocking your deployment process. It however does not end the execution of any binaries which started to run prior to your deployment, and may cause software runtime inconsistencies. Either your software must be able to detect when a new version is deployed, or you kill all instances of it on all machines.

After deploying, you may want to check for deprecated binary directories with older versions of your software, and delete them as convenient.

(3) Remarks

If any severe issue happens to your software, a simple rollback can be performed, using any existing binary directory containing a previous version of it.

Just in case your samba cache does not work well with the junction link, a possible workaround is writing a new dummy file inside the root directory where your junction link points to (you must use the junction link as part of your dummy file path). This should trigger a samba cache update.

References

• The BSDiff 4 algorithm is described in the paper: Colin Percival, Naive differences of executable code, http://www.daemonology.net/bsdiff/, 2003.

• The command line tool ln.exe can be found at: https://schinagl.priv.at/nt/ln/ln.html

My feedback

Thanks @amon and @gapsf for the provided solutions. My experience so far is:

(1) Patching Algorithm

BsDiff 4, a nice algorithm originally written in C++ and probably already ported to C#, can be used for implementing a deployment system which finds binary differences for individual existing modified files, no matter what the file extension is. For other files which shouldn't exist either before or after the patch, simply adding them or removing them accordingly is enough. Everything can be packed into a compressed file and manipulated with your own patch installation system. Easy.

To make sure the patch system creates the new binary directory perfectly, a list with hashes of all files expected to be modified by the patch, and another list with hashes of all files expected after the patch has completed should be good enough for the validation of the patching process.

(2) Deployment

In case of any issues with your patching (for whatever reason you may possibly imagine), my preferred approach so far is first to construct the new binary directory separately. After it is consistently generated, there are two possible approaches:

(2a) Move the old binary directory to a fallback backup folder. Afterwards move the newly constructed binary directory to the official location. But you may not be able to guarantee that no one is using a file located inside your binary directory (e.g. another user from another computer in your network), which could block a directory move operation.

OR

(2b) Alternatively, use a junction link as your official binary directory. It points to the current binary directory (e.g. a directory location out of sight of the user). If the junction link points to the 'bin_v1.0' binary directory, it can be modified during the deployment for pointing to the 'bin_v2.0' binary directory through an one-shot command line, using the tool ln.exe. This prevents any running binary or any open file inside your current binary directory from blocking your deployment process. It however does not end the execution of any binaries which started to run prior to your deployment, and may cause software runtime inconsistencies. Either your software must be able to detect when a new version is deployed, or you kill all instances of it on all machines.

After deploying, you may want to check for deprecated binary directories with older versions of your software, and delete them as convenient.

(3) Remarks

If any severe issue happens to your software, a simple rollback can be performed, using any existing binary directory containing a previous version of it.

Just in case your samba cache does not work well with the junction link, a possible workaround is writing a new dummy file inside the root directory where your junction link points to (you must use the junction link as part of your dummy file path). This should trigger a samba cache update.

References

• The BSDiff 4 algorithm is described in the paper: Colin Percival, Naive differences of executable code, http://www.daemonology.net/bsdiff/, 2003.

• The command line tool ln.exe can be found at: https://schinagl.priv.at/nt/ln/ln.html

My feedback

Thanks @amon and @gapsf for the provided solutions. My experience so far is:

(1) Patching Algorithm

BsDiff 4, a nice algorithm originally written in C++ and probably already ported to C#, can be used for implementing a deployment system which finds binary differences for individual existing modified files, no matter what the file extension is. For other files which shouldn't exist either before or after the patch, simply adding them or removing them accordingly is enough. Everything can be packed into a compressed file and manipulated with your own patch installation system. Easy.

To make sure the patch system creates the new binary directory perfectly, a list with hashes of all expected files to be modified by the patch, and another list with hashes of all files expected after the patch should be good enough for the validation of the patching process.

(2) Deployment

In case of any issues with your patching (for whatever reason you may possibly imagine), my preferred approach so far is first to construct the new binary directory separately. After it is consistently generated, there are two possible approaches:

(2a) Move the old binary directory to a fallback backup folder. Afterwards move the newly constructed binary directory to the official location. But you may not be able to guarantee that no one is using a given binary (e.g. from another computer in the network), which could block directory move operations.

OR

(2b) Alternatively, use a junction link as your official binary directory. It points to the current binary directory (e.g. a directory location out of sight of the user). If the junction link points to the 'bin_v1.0' binary directory, it can be modified during the deployment for pointing to the 'bin_v2.0' binary directory through an one-shot command line, using the tool ln.exe. This prevents any binary being executed or any open file in your binary directory from blocking your deployment process. It however does not end the execution of any binaries which started to run prior to your deployment, and may cause software runtime inconsistencies. Either your software must be able to detect when a new version is deployed, or you kill all instances of it on all machines.

After deploying, you may want to check for deprecated binary directories with older versions of your software, and delete them as convenient.

(3) In case of emergency

If any severe issue happens to your software, a simple rollback can be performed, using any existing binary directory containing a previous version of it.

References

• BSDiff 4 is described in the paper: Colin Percival, Naive differences of executable code, http://www.daemonology.net/bsdiff/, 2003.

• The command line tool ln.exe can be found at: https://schinagl.priv.at/nt/ln/ln.html

My feedback

Thanks @amon and @gapsf for the provided solutions. My experience so far is:

(1) Patching Algorithm

BsDiff 4, a nice algorithm originally written in C++ and probably already ported to C#, can be used for implementing a deployment system which finds binary differences for individual existing modified files, no matter what the file extension is. For other files which shouldn't exist either before or after the patch, simply adding them or removing them accordingly is enough. Everything can be packed into a compressed file and manipulated with your own patch installation system. Easy.

To make sure the patch system creates the new binary directory perfectly, a list with hashes of all files expected to be modified by the patch, and another list with hashes of all files expected after the patch has completed should be good enough for the validation of the patching process.

(2) Deployment

In case of any issues with your patching (for whatever reason you may possibly imagine), my preferred approach so far is first to construct the new binary directory separately. After it is consistently generated, there are two possible approaches:

(2a) Move the old binary directory to a fallback backup folder. Afterwards move the newly constructed binary directory to the official location. But you may not be able to guarantee that no one is using a given binary (e.g. from another computer in the network), which could block directory move operations.

OR

(2b) Alternatively, use a junction link as your official binary directory. It points to the current binary directory (e.g. a directory location out of sight of the user). If the junction link points to the 'bin_v1.0' binary directory, it can be modified during the deployment for pointing to the 'bin_v2.0' binary directory through an one-shot command line, using the tool ln.exe. This prevents any binary being executed or any open file in your binary directory from blocking your deployment process. It however does not end the execution of any binaries which started to run prior to your deployment, and may cause software runtime inconsistencies. Either your software must be able to detect when a new version is deployed, or you kill all instances of it on all machines.

After deploying, you may want to check for deprecated binary directories with older versions of your software, and delete them as convenient.

(3) Remarks

If any severe issue happens to your software, a simple rollback can be performed, using any existing binary directory containing a previous version of it.

Just in case your samba cache does not work well with the junction link, a possible workaround is writing a new dummy file inside the root directory where your junction link points to (you must use the junction link as part of your dummy file path). This should trigger a samba cache update.

References

• The BSDiff 4 algorithm is described in the paper: Colin Percival, Naive differences of executable code, http://www.daemonology.net/bsdiff/, 2003.

• The command line tool ln.exe can be found at: https://schinagl.priv.at/nt/ln/ln.html

My feedback

Thanks @amon and @gapsf for the provided solutions. My experience so far is:

(1) Patching Algorithm

BsDiff, a nice algorithm written in C++ and already ported to C#, or any other similar one, can be used for implementing a deployment system which finds binary differences for individual existing modified files, no matter what the file extension is. For other files which shouldn't exist either before or after the patch, simply adding them or removing them accordingly is enough. Everything can be packed into a compressed file and manipulated with your own patch installation system. Easy.

To make sure the patch system creates the new binary directory perfectly, a list with hashes of all expected files to be modified by the patch, and another list with hashes of all files expected after the patch should be good enough for the validation of the patching process.

(2) Deployment

In case of any issues with your patching (for whatever reason you may possibly imagine), my preferred approach so far is first to construct the new binary directory separately. After it is consistently generated, there are two possible approaches:

(2a) Move the old binary directory to a fallback backup folder. Afterwards move the newly constructed binary directory to the official location. But you may not be able to guarantee that no one is using a given binary (e.g. from another computer in the network), which could block directory move operations.

OR

(2b) Alternatively, use a junction link as your official binary directory. It points to the current binary directory (e.g. a directory location out of sight of the user). If the junction link points to the 'bin_v1.0' binary directory, it can be modified during the deployment for pointing to the 'bin_v2.0' binary directory through an one-shot command line, using the tool ln.exe. This prevents any binary being executed or any open file in your binary directory from blocking your deployment process. It however does not end the execution of any binaries which started to run prior to your deployment, and may cause software runtime inconsistencies. Either your software must be able to detect when a new version is deployed, or you kill all instances of it on all machines.

After deploying, you may want to check for deprecated binary directories with older versions of your software, and delete them as convenient.

(3) In case of emergency

If any severe issue happens to your software, a simple rollback can be performed, using any existing binary directory containing a previous version of it.

My feedback

Thanks @amon and @gapsf for the provided solutions. My experience so far is:

(1) Patching Algorithm

BsDiff 4, a nice algorithm originally written in C++ and probably already ported to C#, can be used for implementing a deployment system which finds binary differences for individual existing modified files, no matter what the file extension is. For other files which shouldn't exist either before or after the patch, simply adding them or removing them accordingly is enough. Everything can be packed into a compressed file and manipulated with your own patch installation system. Easy.

To make sure the patch system creates the new binary directory perfectly, a list with hashes of all expected files to be modified by the patch, and another list with hashes of all files expected after the patch should be good enough for the validation of the patching process.

(2) Deployment

In case of any issues with your patching (for whatever reason you may possibly imagine), my preferred approach so far is first to construct the new binary directory separately. After it is consistently generated, there are two possible approaches:

(2a) Move the old binary directory to a fallback backup folder. Afterwards move the newly constructed binary directory to the official location. But you may not be able to guarantee that no one is using a given binary (e.g. from another computer in the network), which could block directory move operations.

OR

(2b) Alternatively, use a junction link as your official binary directory. It points to the current binary directory (e.g. a directory location out of sight of the user). If the junction link points to the 'bin_v1.0' binary directory, it can be modified during the deployment for pointing to the 'bin_v2.0' binary directory through an one-shot command line, using the tool ln.exe. This prevents any binary being executed or any open file in your binary directory from blocking your deployment process. It however does not end the execution of any binaries which started to run prior to your deployment, and may cause software runtime inconsistencies. Either your software must be able to detect when a new version is deployed, or you kill all instances of it on all machines.

After deploying, you may want to check for deprecated binary directories with older versions of your software, and delete them as convenient.

(3) In case of emergency

If any severe issue happens to your software, a simple rollback can be performed, using any existing binary directory containing a previous version of it.

References

• BSDiff 4 is described in the paper: Colin Percival, Naive differences of executable code, http://www.daemonology.net/bsdiff/, 2003.

• The command line tool ln.exe can be found at: https://schinagl.priv.at/nt/ln/ln.html