将 filezilla 3.3.0.1（以及稍旧的版本也会出现此行为）运行到带有 filezilla 服务器的 Red Hat Enterprise 5x 上，我们在覆盖时文本文件数量翻倍。这似乎会影响 php、js、html 文件，但可能不会影响二进制文件，尽管这尚未经过彻底测试。我们查看了客户端上的设置，发现我们认为存在问题的是“允许恢复 ascii 文件”，它在客户端中指出，如果勾选，可能会导致行尾与平台不同而出现问题，但我们取消了此选项的勾选。
因此会发生以下情况：
我们打开客户端，连接到 ftp 服务器。上传本地文件并选择“覆盖”远程副本。文件大小应该会略有变化（应该会略有增加，例如：117kB -> 118kB），但它不会刷新文件大小。您点击手动刷新按钮，突然报告远程副本的文件大小增加了一倍或更多（例如：275kB）。到底发生了什么事？？
当我们重新下载其中一些文件时，就好像发生了串联（附加了随机的额外内容）。显然，这不会对文件进行微观管理 - 我们的整个系统可能会因此而完全崩溃。请帮忙！！这是权限/所有权问题，还是 filezilla 客户端或服务器发生了一些非常奇怪的事情？
答案1
与 rackspace 交谈后，发现这与他们在 webroot 文件夹中为我们设置的粘性位和 setguid 问题有关，这允许我们写入文件但不能先销毁它，因此最终结果是将新内容连接/附加到旧内容的末尾。我们试图让 web 服务器用户成为所有者，让 web 服务器组与 ftp-ers 组成为同一组，这样 apache 就有所有权和完全访问权限，而 ftp 用户有读写权限，而要提供的全球可读文档有只读权限，如下所示： http://www.washington.edu/itconnect/web/publishing/permissions.html
答案2
尺寸略有差异是正常的，但尺寸不会增加一倍。
尝试以下操作：创建一个包含一段文字的文本文件。上传它。然后关闭 filezilla 客户端并再次打开它并上传它。检查文件大小。如果文件大小翻倍，则在 Linux 服务器上打开该文件（在 vi、emacs 等中），看看它是否确实附加了文件。如果是：
- 尝试调整 FTP 客户端中的设置（传输类型等）
- 尝试另一个 FTP 客户端，看看是否是客户端问题。尝试 WS-FTP 或 FireFTP。
- 尝试从命令提示符访问 FTP
- 尝试从另一台机器上传。
如果在此之后问题仍然存在，则说明问题不在于您的客户端。此时，我会：
- 重新启动 FTP 服务器
- 仔细检查所有 FTP 设置
- 仔细检查权限
- 安装另一个 FTP 服务器程序
到了某个时候，你应该可以排除问题。问题要么出在客户端，要么出在服务器上，因此缩小问题范围应该会有所帮助。
祝你的项目顺利，希望这会有所帮助。
答案3
您有权访问 Red Hat 服务器吗？如果可以，那么该机器上的文件大小是多少？如果我不得不猜测，这可能是 Filezilla 的一个错误，因为快速搜索后出现了一个与您在此处遇到的情况类似的错误报告：http://trac.filezilla-project.org/ticket/4788。