Indeed, this issue is annoying.

The issue that has been referenced is closed, reason cited is that it's a duplicate of this issue.("Circular reference: See Reference, Circular")
This issue is preventing me from discovering files on external drive, robbing me of an hour's playtime with my little brother before I have to catch the bus.

After 4 years do we know if this will be fixed?

Since this issue is still not fixed, I have created a workaround which uses LD_PRELOAD to override the function that Steam uses to find the free space and make it think that the disk has 0% usage. Save the following as fakefree.c and follow the instructions in the header:

/*
 * Intercept calls to statvfs64(), which is used by Steam to determine
 * free disk space, and indicate that all space is available. This is
 * needed to work around the fact that Steam checks available disk space
 * before it checks for existing files.
 *
 * Please ONLY use this preload when you need it to install a game, then
 * relaunch Steam without it so that disk space detection works again.
 *
 * To compile:
 *   gcc -shared -fPIC -m32 -o fakefree.so fakefree.c -ldl
 *
 * To use (after ensuring Steam is not running):
 *   LD_PRELOAD=<path-to-fakefree.so> steam
 *
 * This code is Public Domain.
 */
#define _GNU_SOURCE
#include <stdlib.h>
#include <dlfcn.h>
#include <sys/statvfs.h>

int statvfs64(const char *path, struct statvfs64 *buf)
{
	static int (*real)(const char *, struct statvfs64 *) = NULL;
	if (real == NULL)
		real = dlsym(RTLD_NEXT, "statvfs64");

	int ret = real(path, buf);
	buf->f_bfree = buf->f_blocks;
	buf->f_bavail = buf->f_blocks;
	return ret;
}

fakefree.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

@Adel-Magebinary You'll see that even if it's working properly, as Steam launches both 32-bit and 64-bit executables when it runs. fakefree.so needs to be 32-bit, as the main Steam executable (the one that needs to be tricked) is 32-bit. If it's not working for you, make sure you have a compiler that can cross-compile to 32-bit, and make sure that you pass it -m32 when you build the library.

You can verify that your library is 32-bit by running file fakefree.so. The output should be something like

fakefree.so: ELF 32-bit LSB pie executable Intel 80386 ...

I wonder what can I do on Windows to work around this bug. I installed Windows specifically for Rainbow Six: Siege, which is now 70 GB in size, and my SSD is only 256 GB. Since I have a Russian version of the game, which I didn't ask for (I live in Kaliningrad and play on EU servers anyway), but was forced to use by Steam, for every "new operation" update I have to add English sound files and fix some ini files. After Operation Grim Sky landed, I did this again. This time voices stayed Russian, despite everything I did to change it to English.

I tried reinstalling the game with existing files, but Steam tells me that I can't do that, because I only have 300 MB of free space. But I have all the files, why should I need any free space to do that? So now I have to delete some other useful stuff to just reinstall the game. Thanks Valve for keeping me occupied.

Pretty please fix the damn bug already

I try fakefree.c fix:

LD_PRELOAD=fakefree.so steam
ERROR: ld.so: object 'fakefree.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'fakefree.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Running Steam on debian 9 64-bit
STEAM_RUNTIME is enabled automatically
Pins up-to-date!
[2018-09-10 19:30:05] Startup - updater built Aug 29 2018 20:06:41
[2018-09-10 19:30:05] Verifying installation...
[2018-09-10 19:30:05] Verification complete
html_chrome.cpp (394) : Assertion Failed: CefCrashReportingEnabled()

[2018-09-10 19:30:16] Shutdown

I check fakefree.so with:

file fakefree.so
fakefree.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=f50e19eb6dc0c58bf7e63d67b770b13266f1b18d, not stripped

ldd fakefree.so
linux-gate.so.1 (0xf7f94000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7f69000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7db2000)
/lib/ld-linux.so.2 (0xf7f96000)

All looks normal but can't assertion of code. Any idea how to fix?

LD_PRELOAD needs to contain the full (absolute) path to fakefree.so, otherwise the loader won't be able to find it.

Thanks, but now have error:

LD_PRELOAD=/home/ijurisic/Downloads/fakefree.so steam
ERROR: ld.so: object '/home/ijurisic/Downloads/fakefree.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/ijurisic/Downloads/fakefree.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Running Steam on debian 9 64-bit
STEAM_RUNTIME is enabled automatically
Pins up-to-date!
[2018-09-10 22:23:43] Startup - updater built Aug 29 2018 20:06:41
[2018-09-10 22:23:43] Verifying installation...
[2018-09-10 22:23:43] Verification complete
html_chrome.cpp (394) : Assertion Failed: CefCrashReportingEnabled()

ok I re-compile without -m32 I got result:

LD_PRELOAD=/home/ijurisic/Downloads/fakefree.so steam
ERROR: ld.so: object '/home/ijurisic/Downloads/fakefree.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/ijurisic/Downloads/fakefree.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Running Steam on debian 9 64-bit
STEAM_RUNTIME is enabled automatically
Pins up-to-date!
[2018-09-10 22:38:08] Startup - updater built Aug 29 2018 20:06:41
[2018-09-10 22:38:08] Verifying installation...
[2018-09-10 22:38:08] Verification complete
html_chrome.cpp (394) : Assertion Failed: CefCrashReportingEnabled()

@ijurisic You definitely want to compile with -m32. The "wrong ELF class: ELFCLASS32" error is expected and can be safely ignored. Is Steam starting after printing those log messages? If so, you should be fine; try installing a game. If not, please verify that it starts properly without LD_PRELOAD. If it still crashes, try rebooting or logging out—when I was developing the workaround, I somehow got Steam into a state where it wouldn't start at all, and rebooting fixed it.

@tchebb I don't like how you handled this in your wrapper. I am not in a position to test, but I think something like this would work better:

/*
 * Intercept calls to statvfs64(), which is used by Steam to determine
 * free disk space, and indicate that all space is available. This is
 * needed to work around the fact that Steam checks available disk space
 * before it checks for existing files.
 *
 * Please ONLY use this preload when you need it to install a game, then
 * relaunch Steam without it so that disk space detection works again.
 *
 * To compile:
 *   gcc -shared -fPIC -m32 -o fakefree.so fakefree.c -ldl
 *
 * To use (after ensuring Steam is not running):
 *   LD_PRELOAD=<path-to-fakefree.so> steam
 *
 * This code is Public Domain.
 */
#define _GNU_SOURCE
#include <stdlib.h>
#include <limits.h>
#include <dlfcn.h>
#include <sys/statvfs.h>

void limitField(fsfilcnt64_t *field, fsfilcnt64_t size)
{
        if (*field * size > (((fsfilcnt64_t)INT_MAX) << 9)) {
                *field = (((fsfilcnt64_t)INT_MAX) << 9) / size;
        }
}

int statvfs64(const char *path, struct statvfs64 *buf)
{
        static int (*real)(const char *, struct statvfs64 *) = NULL;
        if (real == NULL)
                real = dlsym(RTLD_NEXT, "statvfs64");

        int ret = real(path, buf);

        limitField(&buf->f_bfree, buf->f_frsize);
        limitField(&buf->f_bavail, buf->f_frsize);

        return ret;
}

It might need a limitField(&buf->f_blocks, buf->f_frsize); line too. The idea being to limit the fields to a 2TB volume size, which is the largest that we can represent with a 32-bit signed integer and a sector size of 512-bytes. The data in #4982 suggests that Steam is trying to emulate that internally.

@ryao you need to clear errno and ret to 0 because the stat call can return errno 75 and steam will bail out. other than that, INT_MAX << 9 seems to be a good value and it's working for me so far

This bug is still a thing and quite annoying! Please do the disk space check after you checked for existing files! Ideally even after finding out how much additional space needs to be allocated.

This should get fixed
I recorded a demonstrative video before noticing that there already exists a report for this: https://www.youtube.com/watch?v=6ZxCIAs5VwI

so what is the current permanent fix for doing this ?

over 20tb free and steam still thinks it has no space to install on Linux I have no been able to install any new games for a year now

can someone just hard code a toggle switch into steam to allow installer to ignore reported space ?

someone closed the other 0 byte issue https://github.com/ValveSoftware/steam-for-linux/issues/5742

they would make more $ if I could install more .. especially during all this covid
oh well I will just keep sniping all the cheap key codes when they pop up and add to collection

all steam seems to pay attention to is free space under home folder

how ever I can no longer install anything again because the fake 2tb was all used up
what other idea's are their ?
I thought this would fake 2tb free space remaining but it fakes a 2tb volume size that steam then virtually fills up

It this still an issue?

Tested this on my deck. Filled my sd card with games, copied a large game to the internal storage, deleted the game through steam, copied the game back and then tried to install the game through steam. Steam doesn't allow it due to "Not enough space". If I delete another game and try the install again, steam validates the game just fine.

This bug is 11 years old now, so it's safe to say it will never be fixed 😒

One workaround you can do is:

1. rsync the files for the game into steamapps/common/
2. Copy appmanifest_.acf into steamapps/
3. Restart Steam

By copying the manifest file, it will think the game is already installed. You can always run a repair on the game afterwards to ensure everything is all good and any needed updates get applied. This is what I've been doing in the meantime, especially now that some UE5 titles need several hundred GB. :/