我大多数编程的本事都用在了实现自身的需求上了，正如置顶的ROM打包解包一样，我只想要一个符合需求的纯净的ROM

恰好几个月前，遇到了一种无法挂载的system.patch.dat，很多人都知道需要去配合system.transfer.list来进行解包后方能修改。记录下我的思考流程

首先，遇到的问题：

正常思维：使用sdat2img.py将system.new.dat转换为system.img，然后挂载进行修改

结果：修改失败

过程：使用fdisk -l查看转换后的img，显示正常

Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)

使用file命令检测生成的system.img检测，显示data正常，属于可挂载img

猜想：是不是因为转换后的system.img存在偏移量？（使用fdisk -l无法看到任何分区）

猜想：是不是因为system.transfer.list进行了修改导致无法转换正常？（和官方对比一模一样，刷机也不会异常）

猜想：update-script做了特殊处理？（查看并无两样）

思考（胡思乱想）：难道ROM作者的水平以经到了如此地步，将文件格式玩到了出神入化的层次？（据我所知，这并不是一种简单事）

过去数月，再次尝试，结果是system.new.dat已经就是可挂载的img并不是新的new.dat格式。

出现这种问题的原因：1，对于这些的思考太过于流程化 2，思维不够天马行空 3，转换以及生成后的img挂载无任何错误提示（挂载后看不到任何文件（ls -a））

最后的解决方案仅仅是：

偶然发现 file system.new.dat 

system.new.dat: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)

本身也就是ext4，直接挂载解决。

不得不说，作者的障眼法，用的很好，今天偶然想起才做了这么一个思维转变。又涨经验了。

你苦苦追寻的真相，其实离你很近，只不过蒙着一层面纱。