I'm trying to build some reasonable strategy for creating and maintaing an offline backup. As I suppose you all have much more experience and knowledge in that matter, I'd be grateful for some suggestions. I've created the separate thread to avoid messing around here (I guess it's better to keep this place focused more on technical aspects of the script).
Thanks!

If you do manage to get it to work under cygwin, please post about it here.

Well, HTMLCXX 0.87 does compile, but libtool can't build the shared library, stopping with:

./configure --prefix=/usr && make:
(compiling everything)
libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified

make LDFLAGS=-no-undefined does not help, then it stops with
(compiling everything)
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: .libs/parser_pp.o: in function `htmlcxx::CSS::Parser::parse(char const*, int)':
/home/lm/hc/htmlcxx-0.87/css/parser_pp.cc:200: undefined reference to `css_parse'
/home/lm/hc/htmlcxx-0.87/css/parser_pp.cc:200:(.text+0x1732): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `css_parse'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:472: libcss_parser_pp.la] Error 1
make[2]: Leaving directory '/home/lm/hc/htmlcxx-0.87/css'
make[1]: *** [Makefile:605: all-recursive] Error 1
make[1]: Leaving directory '/home/lm/hc/htmlcxx-0.87'
make: *** [Makefile:425: all] Error 2

compile target is cygwin-64.

oh the joys of libtool/autoconf :/

if you go into the file css/Makefile and change the line

am_libcss_parser_pp_la_OBJECTS = parser_pp.lo parser.lo

to

am_libcss_parser_pp_la_OBJECTS = parser_pp.lo parser.lo css_syntax.lo css_lex.lo

it compiles. I am only testing it by cross compiling under linux via mingw. But there is a good chance it works for you under cygwin too.
It's probably not how the author intended it, but whatever. lgogdownloader doesn't use the css parser anyway. you could alternatively edit the top level Makefile to skip the css subdirectory entirely.

This helped quite a bit (alongside adding "LDFLAGS = -no-undefined" in the generated Makefile's and prior it, modifying configure.ac prior ./configure with "AC_CHECK_LIB(iconv, libiconv_open)"), but no dice with cygwin64, stopping with:
/home/lm/hc/htmlcxx-0.87/css/parser_pp.cc:200:(.text+0x1732): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `css_parse'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:472: libcss_parser_pp.la] Error 1
make[2]: Leaving directory '/home/lm/hc/htmlcxx-0.87/css'
make[1]: *** [Makefile:605: all-recursive] Error 1
make[1]: Leaving directory '/home/lm/hc/htmlcxx-0.87'
make: *** [Makefile:425: all] Error 2

Within a mingw64 environment, HTMLCXX could be built (with the same settings), but lgogdownloader stops building with a missing ::nanosleep, which is not available under mingw64 ;D This is not lgogdownloader's fault, but mingw64 does not provide a (real) POSIX environment, but Cygwin does... barf out on the " against undefined symbol `css_parse'". My guess is that it has to do with the LDFLAGS.

XDG_CONFIG_HOME=/my/path XDG_CACHE_HOME=/mny/other/path lgogdownloader ....
(I wouldn't recommend setting them permanently in the env since they affect other programs as well). Note that they do not actually have to be different, as there are no conflicts I'm aware of. These replace ~/.config and ~/.cache, respectively.

I'm not going to answer #2 completely. The XML files contain, among other things, the checksums needed to verify the files later on. It's probably not really necessary for this purpose, since the files are almost all self-checksumming (except for the occasional loose file, like the PDF doc for Emperor of the Fading Suns). These are often later converted by gog to zip files, anyway.

In any case, I have ~2TB of downloads, and 88M of XML. Not sure why you have so much.

Thanks for the reply, I know about the XDG vars, but I don't want to mess with those, as they are not exclusive to the program.
Regarding the XML size, I'm suspecting that it might be the block size of my external disk (8MB).

I'd love to try out lgogdownloader as a backup tool on my raspberry pi 2 model B (it has 1GB RAM and a not-so-powerful CPU). Has anyone installed and tested it on a Pi2?

Also, is there a complete guide to the tool somewhere? (I know I should install and run with --help :) just wanted to check the tool's capabilities before actually setting up the hardware and software)

That's why I showed it as part of the command line; that only affects the command being run. You can use an alias or script to save typing. A script has the additional advantage of allowing you to use "${0%/*}" to make those dirs relative to the path of the script, so if it's on the hard drive, the dirs can be set independent of mount point. For example:

#!/bin/sh
case "$0" in
/*) p="$0" ;;
*) p="$PWD/$0" ;;
esac
export XDG_CONFIG_HOME="${p%/*}/../lgstuff"
export XDG_CACHE_HOME="$XDG_CONFIG_HOME"
exec lgogdownloader --directory="${p%/*}/../downloads "$@" 8MB! Why would you do that? Most modern filesystems have extents, meaning that you don't really gain much by making the block size that big (but you do lose a lot). Oh well. At least one thing you can do is trim that dir of files no longer needed. For example, if you use the cache, the following should work (replace /bin/rm with echo to check first):

cd ~/.cache/lgogdownloader/xml
find -type f | while read -r x; do x="${x%.xml}"; fgrep "/${x##*/}\"" ../gamedetails.json >/dev/null || /bin/rm "$x.xml"; done

Alternatively, replace the fgrep with a search for the file in your download directory (e.g. find $dldir -name "$x" | grep . >/dev/null). No file means no need for the XML file any more.

Alternatively, just wipe the XML dir if it bothers you (it will be re-filled on next full download). I'm not sure off the top of my head whether or not that will cause all files to be re-downloaded due to changed profile. Maybe I'll check later and update this post. Until then, unless you're sure about it, don't do that.

edit: disclaimer: I make no guarantees wrt to posted code. If it reformats your hard drive or sets the world afire, don't blame me.

Suggestions?

I have been using lgogdownloader with no issues under WSL2 in Windows 10.

I rebuild my Windows 10 from scratch using 20H2 and WSL2.

I rebuilt lgogodownloader, which went fine as did login and creating cookies, etc.

Now I get an error when executing other tasks:

Examples:
lgogdownloader --check-orphans --verbose --directory /mnt/d/_gog_downloads_/ >/mnt/c/Users/sysadmin/Desktop/orphans.txt

Produces the following output:
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
Getting game names (4/4) 67 / 67
Getting game info 367 / 367

Another example:
lgogdownloader --list

Produces these errors:
HTTP response code said error 100
HTTP ERROR: 404 (https://www.gog.com/account/gameDetails/1444400283.json)
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer0
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.
Error in the HTTP2 framing layer00
Error from reader: * Line 1, Column 1
Syntax error: value, object or array expected.
* Line 1, Column 1
Syntax error: value, object or array expected.

Can someone help me understand how the --check-orphans logic works? I have a number of similar apps and scripts that run against other services besides GoG and I plan to have lgogdownloader start also downloading my gog games to the same location as these other games on a cron. My plan is to put all of these together under one set of folders, regardless of source. I.E.
Installers -> Windows -> [Game Folder] -> Files, where the [Game Folder] don't all come from gog and therefore aren't all managed by lgogdownloader. This means I plan to set Installers/Windows as my top level directory in lgogdownloader. I also want to make sure that lgogdownloader is only keeping the most up to date version of each game. It seems like I can use --check-orphans and pipe that to a script that deletes the list produced but I can't seem to understand *exactly* how the list it creates is produced. If I intentionally add random files to the game folder of a game downloaded by lgogdownloader, --check-orphans doesn't seem to see them, nor does it seem to return new folders I place under the top level lgogdownloader directory. Both of these are my desired behavior, but I want to be certain before I switch the folder to my live folder where the rest of my installers live.

In short, I just want to make sure A) is --check-orphans guaranteed to only return files that lgogdownloader itself created? and B) Is there any other mechanism I need to be aware of where lgogdownloader would delete any file NOT created by it?

lgogdownloader's check-orphans works game-by-game, looking in the directories downlaoding that game would produce. It does not (at present) check for anything in the bare main download directory. It does not keep track of what files it created, so adding random stuff to an individual game's download dir will be reported, unless it matches a pattern in ignorelist.txt. I guess that answers A.

I'm not sure why you're asking B, since you are already aware that even check-orphans doesn't delete the files on its own. If you're asking if files may appear in the list that it shouldn't report, either post-process the list it gives or add patterns to ignorelist.txt. I always manually read the report before deleting the files as a sanity check because e.g. if there was an error reading the cache, files even it created might suddenly appear.

Thanks this is good to know. That said, I don't actually see this behavior when I add a random file to the downloaded file folder. I'm not really ever seeing orphan files reported, despite putting in one that I know should match the check pattern (a random .sh file). I'll look into the ignore file to see if maybe I'm accidentally matching somehow but the check regex that gets shared earlier in the thread should match this file but isn't being reported as an orphan, despite me placing it inside one of the directories that lgogdownloader created.

I'm asking because the doc isn't very clear in many places and you don't know what you don't know? I'm asking because I have a couple of terabytes of data in this folder and it would bad if it got completely mucked up because I didn't check to ensure that lgogdownloader wouldn't make any alterations to existing files on the path under some circumstance I hadn't considered or tested? I'm not concerned with it accidentally deleting it's own files, redownloading my gog library is a small item relatively. I just wanted to be absolutely sure it won't touch other folders under the path it is working on. Obviously, I'm well aware that manually processing the deletes is an option but at that point, it's not really automation, is it? I was hoping that others had a setup like mine and could provide some feedback on how it is working.

I don't know what to say. Works for me. --check-orphans .\* catches any random file I put in a download dir. Of course, giving it such a generous pattern also picks up files it created and shouldn't delete (e.g. serials.txt and changelog*.html); this is a bug that should be fixed. The default pattern has always worked for me for installers & such (.*\.(zip|exe|bin|dmg|old|deb|tar\.gz|pkg|sh)$). It should definitely pick up any file with a ".sh" extension. OK. I'll just shut up, then. Good luck.