Yepoleb: I agree, this was a stupid oversight when the system was designed. It is not easy to fix now though, as this requires changes at every stage of the process, so I think we should give them at least a few weeks of time before complaining again.
phaolo: What a mess..
The problem is that Gog's devs are already changing many installers.
The late they'll acknowledge the issue, the less it will be possible for them to fix it.
Could you guys suggest them any good solution that wouldn't require chunks and timestamp loss? :'(
That's sort of simple on the idea level, the chunk system is producing chunks from actual files, and it has already to produce the extra info about each chunk, which files it does contain (their names and sizes and directory position (which is sort of part of name)), so all you need is to extend this extra info with original timestamp, and then upon unpacking the file to reset it's time to that value. It may be even backward compatible if the original chunk design is reasonable, then the timestamp info can be designed as optional, and the unpacker can unpack both current chunk or new ones. But that's too many "if" and depends how cleanly it was implemented in the first place. Which makes me wonder why they did even bother with these convoluted schemes, if there's ton of high quality open source SW dealing with this, like `rsync`, 7-zip and similar, most of them available either under GPL or even MIT-like licenses, so if the GOG would just pack the separte binary of rsync under GPL and call it externally from their own galaxy client code, it wouldn't matter, etc... the only problematic thing is support for old obsolete OS like windows, but I think most of that SW can be built for windows too, if you bother enough, and it will work reasonably well even there. On modern OS this doesn't even require to build anything, the versions of SW already provided by OS vendor are usually good enough, all you need is to create some thin client calling the SW with correct arguments.