It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
This has been annoying me for a while, but with the large size of XCOM2 and WoTC, it's at the point where I wanted to mention it...

I downloaded the game files to a fast SSD E:, want to install it on another fast SSD D: My system drive C: too is an SSD, but for some reason or other, transfer speeds between C: and the other two aren't so great.

So as I install from Drive E: to D:, all the 70GB go trough C:\TEMP and and only then written to their final destination.

There's a bunch of installers out there which happily will unpack a .bin file directly to it's target destination. Why does the GOG installer create the extra copy/write job on the C: drive?
high rated
avatar
RSColonel_131st: There's a bunch of installers out there which happily will unpack a .bin file directly to it's target destination. Why does the GOG installer create the extra copy/write job on the C: drive?
Some installers require unpacking to a temporary folder first. I don't think it's possible to stop that behaviour at our end, however if you want to change Temp folder location from C to D or E drive then try this:-

1. Go into : Control Panel -> System -> Advanced System Settings -> Advanced -> Environment Variables

2. Click on TEMP and TMP, then "Edit" and change path to new desired location. (Create them if they don't exist). Does that work?
Hi AB2012, thanks for the reply.

I suppose your idea would work, but generally there are good reasons to have my TEMP on C: \

I still think it's a shame that when installing large games, there will be many gigs of temporary files written before writing them to the final disk (even if I moved the TEMP dir around, it's still going to write everything twice). It's just not efficient, it costs additional install time and additional wear on the SSD MLC storage clusters.

Just one of those decisions I can't really see a benefit in, short of saying "that's just how that particular installer works and we don't want to change it".
Post edited March 19, 2020 by RSColonel_131st
avatar
RSColonel_131st: additional wear on the SSD MLC storage clusters.
Sorry, can't help you in your question besides maybe look at how your NVME/Sata SSD's are conected, they maybe sharing the same controller and bring speeds down.

If you're worried about SSD wear, Windows 10 is a hungry hog!! (assuming you use out-of-the-box Win10)
low rated
avatar
RSColonel_131st: There's a bunch of installers out there which happily will unpack a .bin file directly to it's target destination. Why does the GOG installer create the extra copy/write job on the C: drive?
When you say "bunch of installers" (which do not write to the temp directory), do you mean some GOG games, or some non-GOG applications?

To my understanding GOG uses Innosetup or somesuch for its Windows installers. Is it default behavior for Innosetup that it creates temporary files into temp, or can that be selected by the innosetup user?

I guess only GOG staff can answer whether they have any choice on the matter (when using Innosetup), and if so, why they feel they need to use the temp directory. Maybe there is a good reason, maybe not. Maybe. Perhaps. Could be.
low rated
I would have a guess that it works like any decompression software. 7zip, winzip, etc. Extract files to a temporary location, then copy them over to the final destination. It could also be that the files in question need to be uncompressed before they can be operated on, for example if you had and installer in a zip, you can’t run the installer with first unzipping it, and all required files. That would definitely be the case for directx, physx etc.
70gb isn’t too bad, how tiny are your ssd’s? I would suggest you avoid shadows of war or red dead redemption!
avatar
RSColonel_131st: (even if I moved the TEMP dir around, it's still going to write everything twice).
(un)Fortunately, that behavior is a feature of modern computing we can't avoid... unless you set temp to a virtual drive and have A LOT of memory to lessen the write abuse (and be a little faster). :)

https://sourceforge.net/projects/imdisk-toolkit/

Also, transferring between partitions on the same HDD (sda1 --> sda2) is going to be much slower.

EDIT:
http://innounp.sourceforge.net/
https://constexpr.org/innoextract/

Not sure if you also can extract the reg info as well, but luckily most games here seem to run fine without it (like when just moving the game directory to another computer).
Post edited March 19, 2020 by sanscript
avatar
RSColonel_131st: I still think it's a shame that when installing large games, there will be many gigs of temporary files written before writing them to the final disk (even if I moved the TEMP dir around, it's still going to write everything twice). It's just not efficient, it costs additional install time and additional wear on the SSD MLC storage clusters.
I agree. Looking at how modern compression works though, it could be necessary if the file is heavily compressed as a "solid archive". By that I mean in 7zip, you've got the choice between:-

Non-solid = Each file within the archive is individually compressed, dragging and dropping one single file from an archive will quickly decompress it without needing to read the others. Overall compression is lower (can be much lower if many identical files are stored) because the compression doesn't re-use similar data from different files.

Solid = Compression is based off combining all files together as one "solid" block of data. Compression can be much higher if data is reused across files, however dragging and dropping one single file from a solid archive can require ALL files to be extracted / decompressed.

So if GOG's installer use solid compression, it could well need to extract the lot first to work on decompressing them.
Post edited March 19, 2020 by AB2012
According to innoextract GOG uses rar archives.

I tried without --gog and it still worked, doesn't seem to use temp. Have to test further...
low rated

Go into
Why would I? I don't want to go anywhere, thanks for the workaround. Like I said in another post, bug report this so the freakin' developers either create a field in the installer in which you can manually set-up which would be the Temp folder the installer uses or default that Temp to the installation directory. It makes no sense for the installer to unpack data in one drive (C), then copy stuff to your installation drive (D). Waste of space and time. Not to mention fragmentation. Cuz it does it sequentially. Once a file's unpacked, it's moved; and so on. GOG's installer seems to be the worst piece of software and they're comfy with all these insufficiencies. Plain lazy, if you ask me.
You can just create a symlink in Windows, this will solve your issues with space.

1 - Create a new temp directory, say on your D: drive, like D:\Temp - this is where all your temp files will go to in the future.
2 - Locate your current temp directory, it should be in C:\Users\[username]\AppData\Local\Temp\ and try to delete it. Before deleting the temp directory exit all programs, check and kill most processes (Ctrl-Shift-ESC). Google Chrome definitely uses the Temp directory heavily, many other apps probably do as well.
3 - Once you delete the directory, run this command to create a symbolic link:

mklink /d C:\Users\[username]\AppData\Local\Temp\ D:\Temp\

This will create a "fake" directory on C: drive that will simply be actually a link to your D:\Temp directory. If the command works, it will say "symbolic link created". If it says "Cannot create a file when that file already exists", this means that your Temp directory on C: drive still exists (so go to step 2).

Once the link is created, try it out - create a file in D:\Temp directory and it will appear in your C: temp directory. Problem solved.

You can delete the symlink at any time as well, and it will get back to your previous setup.
I just use a virtual 32GB RAMDRIVE and put the system variables TEMP and TMP in it. Never had any issue and the HD/SSD wear is zero.
Post edited April 01, 2021 by Lobuno
avatar
Lobuno: I just use a virtual 32GB RAMDRIVE and put the system variables TEMP and TMP in it. Never had any issue and the HD/SSD wear is zero.
thats a nice solution, provided you have the money to have lots of ram. nited for the future though

I already complained about this on another thread. GOG installers need to change and accomodate to new uses and standard. Cant be a CODEX release of Cyberpunk that install 5x faster than GOG installers. Its insane. People wonder why pirate versions exists... Love GOG, have almost 500 games, but their installers ARENT good. No temp, no repacking, just straight copying, like every other installer around.
Post edited April 01, 2021 by matcarfer
avatar
Lobuno: I just use a virtual 32GB RAMDRIVE and put the system variables TEMP and TMP in it. Never had any issue and the HD/SSD wear is zero.
avatar
matcarfer: thats a nice solution, provided you have the money to have lots of ram. nited for the future though
Well, even if you don't have enough RAM for your RAMDRIVE, you can always use also a swap file to extend the memory, and put that swap file into your C:\TEMP directory, which of course is already in the RAM (and the swap file).

That creates an endless loop, which in turn makes it an endless energy supply. You can power your gaming PC from the generated electricity of that alone, and then some.
Post edited April 01, 2021 by timppu
The main reason why they are doing this is to "obfuscate" the installer data and to make it harder for everyone else (including people who legally obtained the games, but just use Linux) to get to the data inside, but this is in vain. Innosetup now has a special --gog switch specific to deal with these hacked up data.

Really, I should look into doing repacks with the same innosetup installer system (but not hacking up the data) and comparing the results in decompression speed, installer size, total installation time.

No, I keep these builds for myself and I will not redistribute them. Rebuilding an innosetup installer and using the original installation script is not really that complicated, but you have to do your research.

If somebody from GOG (support) is reading and has some brains, GOG should go contact FitGirl and strike a deal with the person to develop a new standard installer for distribution. Naturally, this would also include some contractual obligation not to publish any GOG-derived installers on her/his behalf and sign a non-disclosure agreement. GOG would profit greatly from this persons' knowledge and in addition, GOG would save bandwith AND storage in a gargantuan way.
Post edited April 01, 2021 by coffeecup