背景
公司项目架构升级，服务器由AIX迁移到了Linux。由硬件差异导致了一系列问题。其中之一就是，本地生成tar包送达目标系统后，无法在目标系统前台查看全部文件，部分文件下载后显示文件损坏。
排查
1.我们项目近期并未改动代码，排除项目源代码问题。
2.目标系统近期并未对我方系统送达的文件进行加载策略的更改，排除目标系统的问题。
3.既然出发地与目的地均无问题，那就只能是文件的问题或是传输过程中出现问题。
为保证万无一失，我们在新老系统切换时，进行了一个并行运行的操作，一旦出问题，切换到老系统。而这也为我们查找问题提供了依据。
4.原AIX生成的文件大小与新Linux生成的文件大小存在差异。但是在服务器上解压缩后，文件却又是一样的，真的头大了。
5.将目标系统的文件拿到Windows服务器下使用7z进行解压缩后发现，莫名多出了几个文件、文件夹。而这个多出的文件夹下的文件的名称与外层的文件名称完全相同，那就有可能是文件加载的问题了。将PaxHeaders下的文件使用notepad++打开后发现是atime、mtime、ctime，相当于文件的元信息。
| 简名 | 全名 | 中文名 | 含义 |
| —– | ———– | ——– | —————————————- |
| atime | access time | 访问时间 | 文件中的数据库最后被访问的时间 |
| mtime | modify time | 修改时间 | 文件内容被修改的最后时间 |
| ctime | change time | 变化时间 | 文件的元数据发生变化。比如权限，所有者等 |
6.从目标系统前台下载对应的有问题的文件，使用notepad++打开后，发现与PaxHeaders文件夹下的同名文件的内容完全一致。
7.至此，我找到了问题原因：1）在Linux的命令行生成tar包文件，最终的tar包包含了文件的元信息，在Windows下解压缩后相应的元信息生成了同名文件；2）目标系统的文件加载策略存在些许问题，并不是直接找到该文件，而更像是在某一文件夹下查找目标文件，而且支持子文件夹的查找，并返回找到的第一个文件。
解决
由于是我们系统架构升级，并且没有提前预测到这种情况的发生，也没有提前告知目标系统，让他们来临时修改加载策略肯定是不可能的了，只能依靠自身来解决了。不过还好，一旦定位到问题原因，解决起来也就更加方便了。
Linux下使用tar命令进行打包，既然可以生成元信息文件，那么肯定有参数控制其不生成这些信息文件。
1 | man tar |
原来的命令：
1 | tar -cvf test.tar test |
新的命令：
1 | # 指定了打包格式 |
