探索Android设备中的分区与目录权限问题
在当前的讨论中，提出了一些关于如何在Rooted Android终端（以Motorola G1为例）上测试“挂载点”、“目录和文件权限”的问题。特别是在尝试通过ADB (Android Debug Bridge)将特定位置的文件移动到宿主计算机上时遇到了一些出乎意料的行为表现。
问题描述
使用adb shell连接终端后，首先查看了被挂载为/data/media的分区情况：
$ mount | grep storage
/data/media /storage/emulated/legacy esdfs rw,relatime,upper=0:1028:660:771,derive=legacy,nosplit 0 0
该目录中存在一个文件contacts2.db，其所有者是root，但用户shell没有读取权限：
shell@falcon_umts:/storage/emulated/legacy $ ls -l contacts2.db
-rw-rw---- root sdcard_r 315392 2016-12-02 16:24 contacts2.db
为了解决无法使用adb pull命令将此文件复制到宿主计算机的问题，尝试修改文件的所有者和权限：
root@falcon_umts:/data/media/0 # ls -l contacts2.db
-rw------- root root 315392 2016-12-02 16:24 contacts2.db
root@falcon_umts:/data/media/0 # chmod 755 contacts2.db
root@falcon_umts:/data/media/0 # ls -l contacts2.db
-rwxr-xr-x shell shell 315392 2016-12-02 16:24 contacts2.db
上述命令执行成功，但由于某些原因当退出为root的shell后，用户shell下依然保持了原来的所有者和权限：
root@falcon_umts:/data/media/0 # exit
shell@falcon_umts:/storage/emulated/legacy $ ls -l contacts2.db
-rw-rw---- root sdcard_r 315392 2016-12-02 16:24 contacts2.db
分析
根据讨论中的解析，这一现象出现的原因与Android设备中采用的模拟SD卡文件系统(Emulated SD Card File System)有紧密相关。这个文件系统提供了一种限制性访问模式，在此模式下用户或应用程序不能直接修改该目录下的文件权限和所有者信息以保护隐私安全。
具体分析如下：
1. 挂载点与分区名称差异：设备中实际存放数据的位置可能是/data/media/0，而为了用户体验等因素考虑，设备提供了相对简单的/storage/emulated/legacy挂载点。这就导致用户看到的目录结构与实际文件系统布局略有不同。
2. 权限行为：在shell作为普通用户尝试修改文件的read权限失败的时候，并不代表root账户无法执行这些操作。事实上，通过root账户可以成功完成ls -l命令后文件权限和拥有者信息的更改，但是这种更改并不会影响到文件系统的其他部分，具体来说这里的“所有权”信息仍然会保留原有的设定。
解决建议
对于类似的问题，在需要移动文件或访问非公共区域时，先尝试使用root特权进行必要的修改，然后再通过普通用户身份来验证权限设置是否正确，并确保最终的读写、执行等操作在目标环境上依然可被正常应用。此外也需要熟悉并理解Android设备特有的文件系统结构和权限模型以便有效处理这类任务。
通过上述讨论可以看到，针对特定目录或分区进行细致的操作时需要考虑其背后的实现机制及其对普通用户和管理员角色的不同表现形式。