Do apparent size and allocated blocks agree on Termux private storage, and can target-device tests create hard-link fixtures?
This tests assumptions in PRODUCT.md and its hard-link acceptance criterion.
Environment
Date: 2026-09-13
Kernel: Linux 6.1.176 Android 14, AArch64
Termux private-storage filesystem: F2FS
Fixture: a fresh private directory below $HOME/.cache, removed after the probe
Method
The probe created a 1 GiB sparse file with truncate, a 4 MiB fully written file, and attempted to create a second hard link to the written file.
It recorded st_size, st_blocks, the block unit, and link count.
The sparse file had a 1 GiB apparent size and no allocated data blocks.
The written file reported 4,198,400 allocated bytes for 4,194,304 apparent bytes.
The current Android/Termux environment denied hard-link creation even though both names were in one private directory and the process owned the source.
The process could not read /proc/sys/fs/protected_hardlinks, so the probe did not establish which kernel or Android policy caused the denial.
Conclusion
Apparent bytes cannot substitute for allocated bytes, even on Termux private storage.
The target device also cannot currently create the hard-link fixtures required by an ordinary filesystem integration test.
Hard-link accounting still must handle encountered metadata, but deterministic coverage needs a capable Linux CI filesystem or injected synthetic metadata rather than assuming fixture creation works on Android.
This experiment does not show that hard links can never exist on every target filesystem or Android version.
A denied fixture operation is a capability result, not proof that runtime hard-link handling is unnecessary.
# Private-storage accounting experiment
## Question
Do apparent size and allocated blocks agree on Termux private storage, and can target-device tests create hard-link fixtures?
This tests assumptions in [`PRODUCT.md`](../PRODUCT.md#7-size-accounting) and its hard-link acceptance criterion.
## Environment
- Date: 2026-09-13
- Kernel: Linux 6.1.176 Android 14, AArch64
- Termux private-storage filesystem: F2FS
- Fixture: a fresh private directory below `$HOME/.cache`, removed after the probe
## Method
The probe created a 1 GiB sparse file with `truncate`, a 4 MiB fully written file, and attempted to create a second hard link to the written file.
It recorded `st_size`, `st_blocks`, the block unit, and link count.
## Observations
```text
sparse apparent=1073741824 blocks512=0 allocated=512*0 links=1
allocated apparent=4194304 blocks512=8200 allocated=512*8200 links=1
hardlink=create-failed error=Permission denied
```
The sparse file had a 1 GiB apparent size and no allocated data blocks.
The written file reported 4,198,400 allocated bytes for 4,194,304 apparent bytes.
The current Android/Termux environment denied hard-link creation even though both names were in one private directory and the process owned the source.
The process could not read `/proc/sys/fs/protected_hardlinks`, so the probe did not establish which kernel or Android policy caused the denial.
## Conclusion
**Apparent bytes cannot substitute for allocated bytes, even on Termux private storage.**
The target device also cannot currently create the hard-link fixtures required by an ordinary filesystem integration test.
Hard-link accounting still must handle encountered metadata, but deterministic coverage needs a capable Linux CI filesystem or injected synthetic metadata rather than assuming fixture creation works on Android.
This experiment does not show that hard links can never exist on every target filesystem or Android version.
A denied fixture operation is a capability result, not proof that runtime hard-link handling is unnecessary.