一天 中午的时候，一个开发突然把我拉近了一个群里，但是却没有一个人说话，我进去后，怯生生的问了句：什么事，有人能介绍下吗？ 然后拉我进来的开发开始给我说了下基本的情况，但是我还是没有明白他说的是啥情况。本着定位问题的基本流程：
1.询问目前遇到的问题
2.询问都做了哪些操作
3.询问目前的定位进展
然后又和测试交流了下，排除掉没有违规操作后，基本弄明白的了目前的基本情况：一个产品刚部署完成的时候，进行了一次恢复操作，但是恢复失败了，后续再进行恢复或者备份都会失败,然后便开始了定位解密之旅。
首先查看日志，通过日志看到了和失败相关的一条日志：
zip /home/filepath/test.zip is not a regular file通过这条日志，再查看相关代码，明白了我们这次失败的原因是把相关的文件压缩到制定目录的时候失败了，原因是这个目录有问题。
既然通过日志知道了这个目录有问题，那么我们登入后台查看这个目录有啥问题。
通过cd 命令，切换到home目录下，我们发现这个filepath目录已经不是一个文件夹了，而是变成了一个文件，而且还是一个压缩包，里面还有一个压缩文件, oh my god,这个是什么神仙操作，接着便是开始查询相关的流程操作和相关代码，没发现有任何代码会把这个文件夹变成压缩文件，有一个流程会产生压缩文件，但是操作的不是这个目录啊，定位顿时陷入了僵局。是不是漏掉了什么关键线索呢？
突然想到filepath不是已经变成了压缩文件了吗？于是便尝试解压了下，没想到真的解压开了，从解压的文件里面找到了关键信息：时间，原本的文件名、md5值。
通过时间，找到了最接近这个时间的操作日志，通过这个日志，定位到了相关的文件IA，但是这个文件的md5值，和我们之前解压出来的md5值不一样啊，难道找错了？哦，文件A里面还有一个文件B，文件B的md5值是一样的。
找到了相关的文件后，感觉定位的进度又向前迈了一大步。然后继续梳理流程，梳理代码，最终让我在一个脚本里面找到了一个非常可疑的代码：
cp /root/test.zip /home/filepath这段代码的作用很简单，就是把home目录下的test.zip 文件拷贝到 home的filepath目录下。这条命令真的能实现我们的目的吗？
如果filepath，目录存在的话，当然可以实现，但是filepath目录不存在呢？test.zip 就被重命名为了filepath，这个时候filepath就变成了一个zip文件，而不是我们预想中的目录了。这样也就解释了我们刚开始遇到的问题了，定位到此也就基本结束了，但是为啥会出现这个问题呢？为什么只是在应用刚启动的时候才会出现呢？
接下来又是日志的分析的时刻了，通过日志分析，发现filepath的使用和创建时是在两个流程里面的：
A流程：应用A 在系统启动的时候会去创建filepath
B流程：应用B会调用A 的执行下面的cp命令，将压缩文件拷贝到filepath目录
cp /root/test/zip /home/filepath通过分析日志发现，B流程调用A应用的脚本执行cp命令的时间比A流程创建filepath的时间早了几毫秒，就是这几毫秒的时间，导致了filepath本该是一个目录，现在却变成了一个文件，且导致后面涉及到该目录的流程均不可用。
通过这次经历，我们可以得到下面的教训：
1.使用cp的时候，如果是拷贝到目录下面，尽量在目录后面添加一个"/",如下：
cp /home/test.zip /root/filepath/2.使用到一个路径的时候，注意判断该路径是否存在，而不要盲目使用，对于一些资源，这条也适用
3.涉及到不同流程同时操作一个资源的时候，注意对资源进行保护和读写权限的控制，比如，filepath应该由哪个流程进行创建，一个流程遇到这个filepath这个目录没有创建应该做出什么反应，这些应该都需要考虑到
欢迎关注公众号：壹家大数据
了解更多实际工作中遇到的有趣问题！