b***i
发帖数: 3043 | 1 我司开发一个嵌入式系统，使用Linux，从Windows 7的Windows Explorer可以ftp到嵌
入式的文件系统。我司一位工程师试图删掉ftp里面的一个文件，然后他观察到此文件
的大小从0开始增长，意味着该文件确实被删除了，然后嵌入式系统持续写入该文件（
日志）。
然后他把此文件拖放到桌面。打开此文本文件后，发现文件显示的长度确实和删除后等
待的时间吻合。但是，此文件的开始时间不对，不是删除后的时间，而是0时0分0秒，
即文件在嵌入式创建的时间。
是否说明，Windows Explorer自作聪明缓存了此文件，但是由于文件长度改了，所以
Windows在拖拽的时候把缓存的文件截断，而不是亲自去Linux获得该文件？
登陆Linux，可以看到文件内容确实改了。但是，程序员反对使用sync，或者在程序中
主动sync，会不会Linux返回给Windows Explorer的确实是错误内容，而在Linux命令行
下观测（tail)却可以看到文件的新内容呢？使用filezilla却可以获取真正的文件内容
。是否说明该问题不是Linux造成的？ |
c****3
发帖数: 10787 | 2 Windows浏览器的FTP客户端有各种bug，存在n年了，微软根本不高兴解决，别瞎折腾了。
肯定是以filezilla为主
【在 b***i 的大作中提到】
: 我司开发一个嵌入式系统，使用Linux，从Windows 7的Windows Explorer可以ftp到嵌
: 入式的文件系统。我司一位工程师试图删掉ftp里面的一个文件，然后他观察到此文件
: 的大小从0开始增长，意味着该文件确实被删除了，然后嵌入式系统持续写入该文件（
: 日志）。
: 然后他把此文件拖放到桌面。打开此文本文件后，发现文件显示的长度确实和删除后等
: 待的时间吻合。但是，此文件的开始时间不对，不是删除后的时间，而是0时0分0秒，
: 即文件在嵌入式创建的时间。
: 是否说明，Windows Explorer自作聪明缓存了此文件，但是由于文件长度改了，所以
: Windows在拖拽的时候把缓存的文件截断，而不是亲自去Linux获得该文件？
: 登陆Linux，可以看到文件内容确实改了。但是，程序员反对使用sync，或者在程序中
|
c******n
发帖数: 16666 | 3 我感觉是cache的问题
其实很多ftp client包括winscp你不设置自动刷新的话 服务器端做了变动 client上面
是看不出的
我记得ftp也没heartbeat的吧
话说这样写文件不大好吧 为啥不用sqlite
【在 b***i 的大作中提到】
: 我司开发一个嵌入式系统，使用Linux，从Windows 7的Windows Explorer可以ftp到嵌
: 入式的文件系统。我司一位工程师试图删掉ftp里面的一个文件，然后他观察到此文件
: 的大小从0开始增长，意味着该文件确实被删除了，然后嵌入式系统持续写入该文件（
: 日志）。
: 然后他把此文件拖放到桌面。打开此文本文件后，发现文件显示的长度确实和删除后等
: 待的时间吻合。但是，此文件的开始时间不对，不是删除后的时间，而是0时0分0秒，
: 即文件在嵌入式创建的时间。
: 是否说明，Windows Explorer自作聪明缓存了此文件，但是由于文件长度改了，所以
: Windows在拖拽的时候把缓存的文件截断，而不是亲自去Linux获得该文件？
: 登陆Linux，可以看到文件内容确实改了。但是，程序员反对使用sync，或者在程序中
|
