当前位置:   article > 正文

Linux no such file or directiory ,文件存在但是报文件找不到 异常_linux文件存在 但报错说找不到

linux文件存在 但报错说找不到

1.背景

公司内的一款应用需要用到PDF文件下载的功能,PDF文件由zip包发给现场解压后放到指定目录下,并在配置文件中配置到相应的目录。

2.功能流程

后台数据库有张表配置了文件内的查询关键字,以及文件名信息,前端通过关键字模糊匹配后展示列表,用户在点击某个他想查看的PDF文件后,后台基于文件名以及配置中的文件所在路径信息,获取文件。

File pdf=new File(pdDownloadfPath);

3.现象

当时预生产环境某现场运维小强部署完后,通过前端点击下载发现报错文件不存在,但是文件在相关目录下明明白白清清楚楚的是在的,小强随即联系到了我。

4.排查

我的第一反应是不可能,文件路径搞错了吧--。--! 但是看着现场的错误截图以及文件所在位置,雀食没毛病。而后进行了如下3步常规排查操作:

1).排除文件损坏:文件拷贝到堡垒机后可以正常打开。
2).排除程序权限问题--> 运维现场截图上看到文件权限-rw-r--r--,用户组也没问题
3).通过unanme -a 排除架构问题:x86架构没错

4).磁盘,内存:充足。

这就奇怪了,到这里排查陷入了僵局,我和运维小哥一块丈二和尚摸不着头脑?

突然我想到了一种可能编码,会不会是编码不同? 让小哥通过locale命令查了下果然他们服务器上设置的编码是GBK的,但是我在将文件打包成ZIP的时候我的Mac是UTF-8的,并且启动脚本里设置了-Dfile.encoding=utf-8,简而言之是编码不匹配导致的,最终基于最小改动原则的解决方案是将ZIP在堡垒机里解压后通过FTP上传到服务器目录下,文件就可以正常下载了。

除了上面提到的解决方案,自然而然的会想到的另一种解决方案是改服务器编码,结果是运维小哥解压后的文件乱码了 -_-|| ,莫名其妙 估计是哪里操作不对,但是我在公司测试环境试了是可以的。

至此 排查结束就是编码不一致导致的锅。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/492559
推荐阅读
相关标签
  

闽ICP备14008679号