Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
This topic has been locked 
Discussions Rules and Guidelines
Report this post
We need a NEW VALUE of “StagingFoldersCustom” which can be set to “1” and tells Steam to NOT CHANGE THE VALUE set for “StagingFolders”. A value of “0” would be default (allowing Steam to change as it pleases and requires), of course, in order for it to do whatever it normally does.
Another game update for 80MB and it's copying 40GB over my network (to my auxiliary games storage NAS), both to and from, unnecessarily clogging my local network bandwidth and taking 2 hours, for a 2 minute local update job.
Not even more than one update after I corrected the “StagingFolders” value to “0”, Steam changed the value, once again, back to "1".
Valve, Please, Fix This.
This has absolutely nothing to do with the developers. They do not work for Valve and have no authority nor access to update Steam's inner-workings and configurations.
(It's like calling up your favorite toilet paper brand and complaining how you don't like how they are being OR not being displayed in the very front of your local market/suppliers store - all they do is make toilet paper, they can not control what the retailer does, if they want to put it in weird locations. Ideally the toilet paper is in the toiletries aisle, where it is in every store, where everyone has come to expect it to be, for years, if not decades. A common-sense location, if you will. In this case, Steam, or the 'supermarket' in this analogy, is displaying the toilet paper in a different location, a warehouse, next door, randomly, because there is extra storage, yet the supermarket itself has plenty of space to manage - store, move around and display - the tp.)
If you would read what the issue is, you will understand that the issue is STEAM CLIENT's opting to COPY OVER THE ENTIRETY of the game installation TO A DIFFERENT DRIVE/LIBRARY LOCATION, in order to update (copy over) 80MB of files, only to COPY BACK OVER THE ENTIRETY + THE 80MB of updated files to the ORIGINAL installation directory.
This is an issue due to Steam thinking that there is no space (my best guess) for the game to update on the local drive, but there is 150GB (plenty of additional space, more than 3x it needs). I call this my "guess" as, in the typical update process, Steam copies over the entirety of the game's installation to the corresponding/local drive's "...\Steam\steamapps\downloading\" folder, updating/downloading the new files directly to, then moves/replaces files in the original installation directory. This is why a 40GB game requires about 80GB space (total), which is 40GB additional FREE space + the size of the updated data/content to your 40GB installation. My "guess" is that Steam sees 600GB of free space on the auxiliary drive(s) and thinks the local 150GB (superfast SSD) is somehow not enough. There is no case in where copying files to a different drive/location is faster, when it comes to transferring files just locally, drive-to-drive. Insufficient disk space would be the only reason why you might use another drive's additional space to update the game.
Normally, if you have the game installed (and you have NO OTHER ADDITIONAL STEAM LIBRARY FOLDERS / DRIVES), the game updates by just copying the 80MB into the installation directory. This is a quick 2-minute, download & move-to-install-folder job, ESPECIALLY WHEN YOU HAVE A SSD DRIVE. This is what happens when the "StagingFolders" value is correctly LEFT ALONE to "0" OR it is NOT RE-INTRODUCED, AFTER BEING REMOVED = Steam defaults to using the main installation/library folder, in which the game resides.
Normally, the "StagingFolders" value is correctly set to "0" or is non-existent in the game's .ACF file. This is the value of the game's installation directory, the default main Steam installation drive. Games installed to other drives have their value set to "1" or "2" or whatever additional (non-main directory) library folder, whatever Steam should use to copy over updates to.
It is Steam that is deciding to designate one of the OTHER STEAM LIBRARY FOLDERS that I have, which happens to be a NAS drive, to update the game on. This makes absolutely no sense, considering there is no issue with not having enough space AND this is less than sub-optimal, in terms of efficiency.
I have to MANUALLY UPDATE the game's .ACF file each time any (large game) requires an update, for EVERY GAME that I do not want copying to and from my NAS drive, before the game updates in Steam, in order to avoid this.
This was not an issue before, as I've been running my setup (2 additional Steam library folder locations over 2 different NAS drives) for years. I'm not sure how long the "StagingFolder" value has been around, also, how recent Steam has been set to automatically decide the optimal value for - especially when a value is different from the main install folder and changed to use an alternate libary folder.
As I mentioned earlier, the simple fix to this (NOT ONLY A FIX, AS THIS SHOULD ALREADY BE A BASIC, NECESSARY OPTION) is to add a value ("StagingFoldersCustom") that can be set ("0" = default value, Steam decides what it normally does and "1" = value indicating that Steam SHOULD NOT BE ALLOWED to change the value set) so that Steam DOES NOT DECIDE BY ITSELF to change the "StagingFolders" value to something else.
Another 23MB update, copying the ENTIRETY of the 40GB game OVER THE NETWORK to my NAS drive in order to move an insignificant amount of data into the installation folder, just to copy it back over the network to my local drive.
This is torture.
Another update... and by the looks of it Steam has reset the value again:
https://imgur.com/a/AdPf7pe
Steam chose to arbitrarily select another library folder (also NAS drive), this time going from the "0" that it should be and going for "2", different from the usual "1".
Yet again, I had to stop downloads, quit out of Steam, delete the content in the WRONG DRIVE's downloads folder, update the StagingFolders value on the local drive to "0" and restart Steam. Did this twice, as Steam decided to change the value right back, right after I changed it.
I would submit a support ticket, per usual, but this is a Steam-client issue and there appears to be no option to report Steam bugs directly...
As you might have guessed, another update and another chance for Steam to be mismanaging the .ACF file.
I don't mean to be rude, but it appears that you are unable to grasp what the issue here is.
This is a Steam client issue. You can literally install any game and it will be prone to the same exact issue. If you are to say that every developer on Steam compiles their game the wrong way, then perhaps it is Steam that is the issue. That aside, this has nothing to do with compiling the game or how the game is compiled - the issue is with how Steam updates the game files.
If developers all have to add in a special workaround to fix this, why not just fix the issue by default, within the Steam client?
Also, apparently updating the StagingFolders value to the correct local drive ("0") does not work anymore and Steam is just installing the game to the NAS drive...
Downside, STEAM IS DOWNLOADING 23+GB OF FILES, as apparently the values stored in the .ACF are used for quick 'delta' updates (what should have only been 23MB of download).
After doing this, the StagingFolders line is removed entirely. Perhaps it is better to remove this line than to change the value.
blub.
Thanks for the info.
However, the issue I appear to be having seems to be related to Steam's management of game libraries (folders/drives/ect) and using one libraries' space (Library B) to update games from another library (Library A).
If I have just one Steam library folder (Library A), this magically becomes a non-issue, as Steam uses just that library (and drive) to update the game. Due to the fact that I have more than one library specified in Steam, and moreso that these additional libraries reside on different drives, which are located over the network on a NAS, the issue thus arises.
Sure, the developer can change how the game files are structured with updates, but this has nothing to do with the fact that Steam is randomly deciding that it needs the space on another, separate, drive in order to simply update files.
Do you have any insight as to why Steam is doing this?
Let me know if I'm missing something here, as this has only recently become an issue and it clearly appears as though Steam is at fault. Just use the drive/library that the game is installed in to update said game - why does Steam assume that using another library/drive is an acceptable option? Space is not an issue, in this case, but cross-drive transfer speed is almost guaranteed to be a bottle-neck.
Now the StagingFolders value is impotent - it does not matter if you change this value, as Steam will ignore whatever you set and arbitrarily decide upon a library folder/drive to update the game to.
Not sure if this was changed with a Steam client update recently, but it's quite broken now.
I have to COMPLETELY REMOVE/DISCONNECT the additional Steam library folders (physically disconnect / unmap the drives) as Steam does not allow removing library folders within the client settings temporarily, so that the damned Steam client uses the correct (default) drive to update the damned game.
Please FIX this, as it appears the Steam client was updated for the worse (after recent client updates, modifying the StagingFolders value no longer works).
I understand why they want to make a copy of a file before installing the delta patch (in case it gets damaged you still have a working copy of the previous version), but the StagingFolder changing is just nonsense.
The best part is I have Steam on a different SSD, and it's not copying the stuff there... it's still using the mechanical hard drive.
My setup is this:
C: is an SSD with Windows and a bunch of non-game stuff.
D: is a mechanical hard drive with a Steam Library
H: is an SSD that has Steam.exe and another Steam Library
J: is an SSD has a Steam Library with Path of Exile and pretty much nothing else
Whenever Steam on H: decides to update PoE on J:, it copies the 36 GB "content.ggpk" file to D:\SteamLibrary, patches it there, then copies it back to J: ... aagh.
I used Everything (a search tool) to look through literally every appmanifest file I have (text search) and literally the only one out of 445 that has a "StagingFolder" set is, you guessed it, Path of Exile!
Hey buddy, thanks for posting and sharing your issue :)
Yeah, this sounds about right. I resorted to just deleting the .ACF once (allowing Steam to verify existing files) and it ended up correctly updating on the same SSD drive as the install - however, instead of downloading just the 25mb or so it needed, it ended up downloading some additional 30-40gb, as it somehow needed extra files in order to rebuild or verify, no clue.
Second time around I disconnected all drives, aside from the main steam install drive (which so happened to be the game drive for the game I had issues updating). I realize this latter method may not work if you don’t only have just one library folder specified (at least until your game updates).
I contacted Valve about this, as it appears to be a major flaw and issue that’s somehow gone overlooked. The reply I received from support said they’d ‘look into it, but won’t be able to notify me if they take any action or fix the issue.”
Not sure why they wouldn’t be able to notify or send me a message when its patched and part of officially released update notes, but there it is.
The best we can do for now is raise awareness and encourage others to reply and bug Steam about fixing this, I suppose.