S2Arm needs more space, or disk usage looks wrong

Identify the drive and stage that need space. Separate build estimates, peak disk usage, exFAT allocation and phone storage.

Separate three locations: the originals drive, the computer's working game library and the phone's storage. Free space on one cannot replace space needed on another.

Record where, when and how much

Identify whether import, build, transfer or first phone import failed.
Read the task's drive, estimated requirement and available space. Do not rely on another drive's free space.
Record S2Arm version and the library filesystem. Check drive Properties on Windows or disk information on Mac.
Keep external storage connected and the working library outside cloud sync folders.

There is no universal “twice the original size is enough” formula. Final file size, temporary stage usage and the peak across a complete build are different measurements.

Why an update may still use a lot of disk

v0.2.6 reduced temporary files in parts of translation, but the notes had not measured every game's full build peak. A later Windows comparison in #329 still peaked around IPA finalization and had similar overall peaks across two versions. A stage improvement is not a universal whole-build reduction.

Free other data you know you no longer need, or choose an already suitable location with room. Do not start by deleting saves, originals or your only successful output, and do not blindly run old internal-folder cleanup commands.

exFAT: file size is not allocated space

Many small files on a drive with large allocation units can occupy much more space than their nominal sizes. In #444, the maintainer identified large-cluster exFAT as part of the increase and corrected the earlier suspicion of duplicate import.

For a first working library, prefer an existing local APFS location on Mac or NTFS/ReFS on Windows, subject to launcher checks. Reading originals from exFAT does not establish that it is suitable for every working library.

Do not format your existing drive just to get past a step. Formatting erases data; choosing another already usable location can be a simpler diagnostic.

An unusually high estimate is not proof of duplicate import

The final #444 reply separated an earlier v0.2.2 extraction multiplier from a later v0.2.5 overlapping-content calculation. A fix was announced for v0.2.7, but that release's public notes list only the encoding fix. This guide has not established whether the space fix is in the distributed package.

The reviewed v0.2.8 notes do not confirm that space-estimate fix either. Its Windows default-library-folder change addresses setup conflicts, not a measured reduction in build storage. Keep checking actual available space and the reported stage.

Record the current version, estimate and actual free space, then check again after an update. Do not copy another game's estimate or use “continue anyway” for every space warning.

Phone storage and runtime memory are separate

Resource import needs phone storage; running a game can also need memory and temporary files. #483 led to a post-unpack space recheck in v0.2.6, whose notes explicitly lacked a same-scenario device reproduction. It is not an all-crashes fix, and the thread's frame-rate question was separate.

Success check: The original failing stage passes and the complete build or import finishes. A green check at task start is not enough. If it fails, report the location, stage and error. This site has not measured disk peaks.