dotnet-install.sh fails to install on systems with a small /tmp

[khyperia]

I have a VM with a small amount of RAM, 500MB. The /tmp tmpfs on the system is 250MB. When running dotnet-install.sh, extracting the zip fails due to running out of space (the zip is 134MB, extracting at least doubles that size, so it requires at least 268MB)

Why is /tmp even used in the first place? I can perhaps understand it for the zip download, but why not just extract it directly to the output directory? (The best solution, in my opinion, would be piping the download of a tar.gz into an extraction into the destination directory, requiring no temporary files at all...)

Also important to note is that the script fails to clean up after itself upon failure, leaving these hundred-MB files and folders lingering around in /tmp.

---

Expected behavior: the cli successfully installs, because installation shouldn't depend on having a large amount of RAM.

Actual behavior: Failure due to lack of RAM allocated to the /tmp tmpfs.

[donJoseLuis]

We have neither heard nor observed this issue. Seeing how this item was created 3.5 years ago, we'll close it; however, if you are impacted by this, please reopen it & we'll detect it in our weekly triage.

[khyperia]

This has not been fixed, still happens, and still fails to install. I see that a .tar.gz is now downloaded instead of a .zip, so it'd be really fantastic if the download was piped directly into the extraction into the final installation directory! Even just doing cleanup after itself would be really wonderful (including on failure to install).

(also note that I do not have permissions to reopen the issue, so I can't do so as you requested)

[donJoseLuis]

Hello @khyperia , thanks for letting us know. The issue is reopened; we'll track it under an effort to essentially re-engineer the scripts.

[bekir-ozturk]

Hi,

Cleaning up the extracted archives will be delivered by #45. Hopefully, that should partly fix the issue. However, we will not be able to deliver the feature to pipe the data directly into the target folder without downloading the archive file onto the disk first.

The scripts are being put into "maintenance mode". This means that the scripts and their ecosystem (i.e. website and feeds) will continue to be monitored, but no new features will be delivered. We are still committed to maintaining the scripts’ high availability and we will quickly respond to any incidents.

As part of this effort, we are closing the issues that aren't planned to be delivered. Unfortunately, this issue is one of those that didn't make the cut, and therefore will be closed.
If you think this is a must-fix issue before maintenance mode begins, please feel free to comment.

Thanks

[exzile]

This issue has risen for me on debian on an SBC