fix(arcup): check disk space in TMP_DIR, not just BIN_DIR

[batuhankocyigit]

Summary

main() in arcup/arcup calls check_disk_space exactly once, on BIN_DIR:

mkdir -p "$BIN_DIR"
check_disk_space "$BIN_DIR"

But the release archive is downloaded into TMP_DIR (mktemp -d, usually
/tmp) and also extracted there before the binaries are copied to
BIN_DIR. So TMP_DIR briefly needs to hold both the compressed archive
and its extracted contents (~2x the final install size), and it is never
checked at all.

TMP_DIR and BIN_DIR are frequently different filesystems — e.g. /tmp
is a small tmpfs in many containers/CI images while BIN_DIR
($ARC_DIR/bin, under $HOME) sits on a much larger disk. In that case the
BIN_DIR check passes even though there isn't enough room in TMP_DIR, and
the user gets an opaque curl/tar failure instead of the intended
friendly Insufficient disk space error.

Fix

Add a check_disk_space call for TMP_DIR as well, with a higher
threshold (1000MB vs. the 500MB default) since it temporarily holds both
the archive and its extracted contents.

check_disk_space "$BIN_DIR"
check_disk_space "$TMP_DIR" 1000

Testing

• Added test_check_disk_space_rejects_insufficient: direct unit test that
  check_disk_space errors with Insufficient disk space when the
  required size exceeds what's available.
• Added test_main_checks_tmp_dir_disk_space: end-to-end regression test.
  Points TMPDIR at a directory whose fake df output reports ~1MB free
  while BIN_DIR reports effectively unlimited space, runs the real
  arcup binary via arcup -i 1.2.3, and asserts it fails with the
  Insufficient disk space message (proving the failure comes from the new
  TMP_DIR check and not the pre-existing BIN_DIR check).
• Ran the full suite locally: all 27 assertions pass (25 pre-existing + 2
  new).

$ bash arcup/test_arcup.sh
...
ok - install_binary rejects symlink
ok - check_disk_space rejects insufficient space
ok - main rejects insufficient TMP_DIR disk space

No functional changes outside arcup/arcup and arcup/test_arcup.sh.

[osr21]

Verified this independently at ec3a656 — the premise, the placement, and both tests check out, and running your e2e test against main surfaced a second, related defect worth a maintainer's eye. Two review points at the end.

Confirmed on main:

• check_disk_space has exactly one call site (BIN_DIR, line 753), while the archive is downloaded (line 775) and extracted (line 818) into TMP_DIR before install_binary copies out — so the ~2x transient footprint claim is structurally right. TMP_DIR is assigned at line 50 (mktemp -d), so it's live at the new check's position, and check_disk_space already takes the optional MB argument (default 500), so 1000 slots into the existing signature without touching the function.
• Full suite: 27/27 on Linux, and the regression test does fail on main — with main's arcup and this branch's test file, main() sails past the fake 1MB TMP_DIR and dies much later with a misleading error.
• Merge-tested against the open arcup queue: applying fix(arcup): a release is newer than its own pre-release #300, fix(arcup): accept a valid checksum written in uppercase hex #302, and fix(arcup): accept checksum files without a trailing newline #243 in sequence and then this PR merges clean at each step — the main() hunk and end-of-file test additions stay disjoint from all of them.

Review point 1 — the 1000MB constant is ~5.4x the measured need. I downloaded and extracted the real v0.8.0 x86_64-unknown-linux-gnu release: 52MB archive + 133MB extracted = 185MB peak in TMP_DIR. Requiring 1000MB free means a machine with, say, a 512MB tmpfs /tmp — a common container default — that installs fine today gets hard-refused after this PR. That converts a false negative (no check) into false positives (spurious refusals), which is the worse failure mode for an installer. 250–300MB keeps comfortable headroom; even the plain 500 default is 2.7x measured peak. Worth sizing to the data rather than doubling on instinct.

Review point 2 (observed, not this PR's fault) — on curl 8.14.x, download_file's error handling is silently defeated. Running your e2e test against main on a box with curl 8.14.1, the failure message wasn't download_error's friendly output — it was Checksum file is empty: …. Cause: curl 8.14.0/8.14.1 return exit 0 on a 404 when --retry is combined with --fail (upstream curl/curl#17554, fixed in later releases; --retry 0 or no retry exits 22 correctly). Since CURL_RETRY_ARGS includes --retry 3, if ! curl_with_headers …; then download_error never fires on those curl versions, and a failed download cascades into whichever downstream step trips first. Everything still fails closed — checksum verification refuses the install — but the "opaque error instead of the friendly one" problem this PR fixes for disk space exists for downloads too, on a curl line that shipped in current distros/nixpkgs. A [[ -s "$output_path" ]] check after the curl in download_file would immunize it regardless of curl version. Happy to see that spun off separately; flagging it here since this PR's own test is what exposed it.

The recurring gap: no ARCUP_INSTALLER_VERSION bump. The script header requires an increment for any modification and the self-update check depends on it. Note the coordination problem already queued: #300, #243, and #262 each claim 0.2.0 → 0.2.1, so whichever subset lands, later ones renumber at land time — but the bump should be present in the diff.

[batuhankocyigit]

Thanks for the thorough verification genuinely useful.

Point 1 (1000MB → 300MB): Fair, that was instinct ("2x the default") not
data. Dropped it to 300MB, which keeps ~60% headroom over your measured
185MB peak (52MB archive + 133MB extracted) without over-requiring on
small-tmpfs hosts. Updated the comment to cite the measurement instead of
justifying by instinct.

Point 2 (curl 8.14 --retry/--fail bug): Agreed this should be separate —
it's a real, independently-reproducible issue (upstream curl/curl#17554)
that's orthogonal to disk space, and folding it in here would just slow
this review down. Opening a dedicated issue for it referencing this thread.

Version bump: Bumped ARCUP_INSTALLER_VERSION 0.2.0 → 0.2.1 per the
script header rule. Understood this may get renumbered at merge time
depending on what lands first among #300/#243/#262 — leaving that
coordination to whoever merges.

Pushed both fixes to the same branch. 27/27 still green locally.

[batuhankocyigit]

Opened #309 for the curl 8.14 issue.

[ZhiyuCircle]

Hi @batuhankocyigit,

Thank you for your interest in contributing to Arc Node, and apologies for the delay in getting back to this PR.

We're closing out the pull request backlog that predates our current contribution policy. This PR is being closed because it does not reference a GitHub issue. All PRs must reference an existing issue using the format Closes: #XXX, and the author must be assigned to that issue before the PR is opened.

This is not a judgement on the change itself. If you'd still like to land it:

1. Open an issue describing the problem, or find the existing one
2. Comment on the issue requesting assignment, and wait for maintainer approval
3. Open a fresh PR once you have been assigned

Please see CONTRIBUTING.md for details. Thanks again for taking the time to contribute.