How do I access $HOME/storage Termux directory on Android Pie with a GUI File Explorer?
In Termux I print the working directory with pwd and it shows $HOME/storage as:
/data/data/com.termux/files/home
My internal storage looks like this:
.
├── Alarms
├── Android
| ├──data
| | ├── ...
| | ├── com.termux
| | | └── files
| | | └── 0 items
| | └── ...
| └── ...
├── DCIM
├── Download
└── ...
My external storage looks like this:
.
├── Android
| ├──data
| | ├── ...
| | ├── com.termux
| | | └── files
| | | └── 0 items
| | └── ...
| └── ...
└── LOST.DIR
Neither my internal storage, nor my sd card, contain a /data/ directory at the root level. Where is this /data/ directory? For that matter, where is the root /storage/ directory? Where is the root /emulated/ directory? Where are any of these directories and why cant I access any of them?
Answer
If you did termux-setup-storage previously, create random_file.txt file in $HOME/storage/shared. That'll be created on /sdcard/. But you don't need to do that hassle. Just grant Termux Storage permission and save directly to /sdcard/ e.g.
echo xyz >/sdcard/random_file.txt
$HOME/storage is actually /data/data/com.termux/files/home/storage which is not accessible to other apps without root access. That's how Android's security is designed.
Where is this
/data/directory?
It's a partition named userdata mounted in rootfs at /data. For details see How disk space is used on Android device?
where is the root
/storage/directory?
It's also a directory in rootfs where tmpfs is mounted. Contents of this directory look different to different apps because of mount namespaces and filesystem emulation.
Where is the root
/emulated/directory?
It's at following three locations:
/mnt/runtime/default/emulated
/mnt/runtime/read/emulated
/mnt/runtime/write/emulated
Where are any of these directories and why cant I access any of them?
These directories are what you see when you open a file explorer app. Emulated filesystem path is /sdcard.
On Android 6+, /data/media is emulated to three VIEWS mentioned above. One of those is bind-mounted to /storage/emulated depending on app's Storage permission status. emulated directory contains User_ID's of all users (if there are multiple users or profiles). Device owner is always 0. So /sdcard points to /storage/emulated/0. It's the storage which apps can read and write.
Additionally apps can read and write to their private data directory in /data/user/ (which is /data/data/ for device owner). For details see What is /storage/emulated/0/? and What is the “u#_everybody” UID?.
From your comment:
Can Termux write to the actual SD card physically inserted into my phone? If so, how?
Apps don't have filesystem level write access to external SD card except those using SAF APIs. Quote from official documentation, Termux doesn't have support for SAF:
Why does Termux have read-only access to the external SD card?
On recent Android versions, the write access to the external SD card is done over Storage Access Framework. It is not possible to provide it's API to the command line programs.
However apps can always (with and without Storage permission) read and write to their private directories in shared storage i.e. in Android/data/ directory (and some others) on /sdcard/ and external SD card. For details see How to move files to external SD card on a non-rooted Android?
From your comment:
So basically I don't have access to my own devices root directory, without rooting the device? I can only start at the third level? That's frustrating.
/data partition also contains system settings including sensitive data like password databases (though not saved as plain text). So /data isn't accessible without root in order to:
- Protect apps' private data from other apps (every app is a UNIX user with unique UID)
- Protect system data and settings from bad apps and malware
- Isolate users/profiles from other users/profiles
- Not let apps access shared storage without Storage permission granted
- Enforce APIs by Android framework so that apps can't use system resources and read/manipulate device information and settings without proper permissions
And possibly there are other reasons. For details see Are multiple-users protected from each other differently than apps?
No comments:
Post a Comment