I'm not really an expert, but I think it could be fair use if let's say the patch was distributed to those who already own the game. But if someone who doesn't own the original gets the transformative work, it doesn't sound like fair use to me really. But anyway, I personally don't mind people doing it, since it's obviously something that GOG had to do, and they didn't.

I learned quite a bit from this thread about making binary patches :) And it's an interesting catch indeed (with ability or inability to recover the original).

The discussion is futile :)

I can extract the new files out of a rdiff patchset, it's just a little more complicated. So to be blunt: The re-distribution of the official patches by users is always a copyright violation. And as soon as I get a takedown request by GOG or Obsidian, I'll remove the patchsets from my server.

The main goal of this exercise was to show, that it is possible to write a simple patchtool with reasonable stability for Linux in about one day. Maybe everyone who wants GOG to get their things together should open a ticket about smaller Linux patches and send them a link to my github repo. My script is licensed under Apache 2.0 licence, so it can be used/modified freely.

I agree, the only way to stay on the legally safe side would be if GoG would distribute the patches.

The method using xdelta3/patchmonger has three major advantages

- easier to apply - so more suitable for new(er) Linux users
- considerably smaller patch set size
- less fragile wrt. uid/gid

and the single dependency on xdelta3 is likely not harder to satisfy than the dependency on rdiffdir. For the time being I propose to stay with patchmonger until GoG reacts in either way - hopfully by providing patchmonger patches themselves.

Well to continue the academic discussion: at a low level a rdiffdir patch without the target data is effectively a XOR cipher text without a key. Extracting usable data may prove to be a formidable task, if not neigh on impossible.

In any case, if you feel like you're on legally questionable ground: I would highly encourage you to not proceed. It's just not worth it. Instead: write in to GOG; they have the power to provide patches legally.

Naturally, I hope that GOG will use patchmonger or a similar approach to distribute patches for games on Linux.

I am working on a new release of patchmonger, which does not store the new files directly but as a VCDIFF. You still can reconstruct the new file from it, but at least it's not the original file anymore. Another benefit from this is, that the new files are also compressed with LZMA which will make the patches a bit smaller (depending on the size of the new files).

If interested, you can check develop branch here:

https://github.com/neovatar/patchmonger/tree/develop

I probably should have checked this thread earlier so I wouldn't have done unnecessary work.
I see that tseliger had similar idea with patchmonger.
patchmonger seems to do almost exactly the same thing as my patcher.

Perhaps this tool is useful for someone.

Here is xdelta3dir
As the name implies it uses xdelta3 to create delta files from directories.

https://sites.google.com/site/gogdownloader/xdelta3dir-1.0.tar.gz
md5: 0bf8d2c4e84ea1b4f36e888b21bba313
sha256: 46752fa1a681863543640bf4cfaa82e7739a98aa2255b1a01d225fe74636a289

Required libraries:
libboost-system
libboost-filesystem
libboost-date-time
libboost-program-options
libtinyxml
librhash
liblzma

tar -xvzf xdelta3dir-1.0.tar.gz
cd xdelta3dir-1.0
make release
sudo make install

To create a patch To use delta files also for new files To apply a patch Here's 1.03 to 1.04 patch created with it
https://sites.google.com/site/gogdownloader/gog-poe-linux-patch_1.1.0.2_1.2.0.3.7z
md5: 080e23a38fc7e4542e7dde99dcb38fdf
sha256: 89d28123d15f05137c5015ab17d9af4c8bcc7f0602594fa536ee8a2e3f6fb906

This lies in the nature of introducing new files - adding some obfuscation through rdiffdir or vcdiff does not add to. You have to transport the information and the only thing you can do is providing the data. Any obfuscation does not alter this. So long story short - plain lzma/bzip2/lz0/gzip whatsoover compressed files are as good or bad as VCDIFF or even the original file.

So many people reinventing the same wheel :)
Searching for something similar I found this:

https://github.com/endlessm/xdelta3-dir-patcher

I haven't tried it yet, so I don't know if it could be used as-is to patch GOG games, but maybe it's worth a try.

I am not doing this for obfuscation, but to use the LZMA compression built into xdelta3.


I know this tool, I aimed for minimal external dependencies: bash + xdelta3 ;)

I actually just learned that the man page for rdiff is wrong. It says that the source during a patch can be stdin; but that feature wasn't implemented [I tested the zip workflow without the pipe]. It's possible to make a version of rdiff do that, but at the expense of the overall delta size. http://sourceforge.net/p/librsync/mailman/message/959602/

Having said that, here's a workflow using cpio:

cd ./old-version
find ./game -depth -print | cpio --create --no-absolute-filenames --owner=0:0 | rdiff signature - ../old-version.sig

cd ./new-version
find ./game -depth -print | cpio --create --no-absolute-filenames --owner=0:0 | rdiff delta ../old-version.sig - ../new-version.delta

cd ./old-version
find ./game -depth -print | cpio --create --no-absolute-filenames --owner=0:0 > old-version.cpio
rdiff patch old-version.cpio ../new-version.delta | cpio --extract --no-preserve-owner --make-directories
rm old-version.cpio

I was hoping to use the above to solve the doubled filesize problem; but it sounds like that wont be possible with a stock rdiff. I did notice that the cpio/rdiff process does produce smaller deltas than rdirdiff; so perhaps rdirdiff is using a modified rdiff.

Does the '--owner=0:0' option avoid the owner/group bug that’s been reported with the rdiffdir patch?

(just broke my distant access to my server last night, I can’t run tests myself for the next couple days)

Yes, that's the intent. But I haven't done thorough testing.

The "--no-preserve-owner" switch during the extraction, is to also get it to use the user's existing values.

I updated patchmonger:

[url=https://github.com/neovatar/patchmonger ]https://github.com/neovatar/patchmonger [/url]

* New files are also handled as VCDIFF
* Backup and rollback of changed files on failed patch

The script is using bash, grep, sed (which are included in almost all Linux distros by default). The only thing you probably need to install is xdelta3 with LZMA support. Usually you can install it easily from your distros repository (e.g. via "sudo apt-get install xdelta3" on Ubuntu). I may include a portable binary of xdelta3 in the future, but I would need to compile against musl or ulibc, so don't hold you breath.

The script should work with all GOG Linux games tgz installers (e.g. Wasteland 2).

I updated my two patch sets for PoE: http://stuff.neovatar.org/patchmonger_poe/

gog_poe-patch-1.0.0.1_1.1.0.2.tgz is game version v1.0.3.503
gog_poe-patch-1.1.0.2_1.2.0.3.tgz is game version v1.0.4.540

I used these sets to patch my version and it was identical to the downloaded 1.2.0.3 complete tgz.

I posted some benchmarks back on the inXile forums: https://forums.inxile-entertainment.com/viewtopic.php?f=34&t=11081&start=60#p149991

To summarize:

949.7MiB [baseline]

[patchmonger - xdelta3]
294.7MiB
00:04:15
~3x smaller (68.9% reduction)

[patchmonger - bsdiff]
25.7MiB
02:37:05
~37x smaller (97.2% reduction)

[rdiffdir - rsync]
158.9MiB
00:01:14
~6x smaller (83.2% reduction)

Looks like a great tool! But, stuff.neovatar.org is down. Is there another source for the Linux patches?