【问题标题】:What is the result of a stat() call on a file being written to?对正在写入的文件调用 stat() 的结果是什么?
【发布时间】:2017-01-10 09:01:14
【问题描述】:

在 Solaris 10 上的 stat() 系统调用有一点问题。我正在做 FTP,同时对正在写入 的文件调用 stat(检查文件大小)同时通过 FTP。

假设在调用stat() 命令/调用(并行)时将文件写入目录。那么st_sizestruct中的结果会是0吗?

或者stat 调用会在 FTP 发生时反映文件的当前大小?

FTP 是否像我认为的那样具有事务性?

【问题讨论】:

  • 它是否是事务性的实际上取决于实现,而不是 FTP 协议本身。我不记得 FTP 是否在传输之前传达了文件的大小(我认为确实如此),但在这种情况下,它也可能预先分配空间并且看起来它的大小正确但实际上并没有所有数据然而。这是如何发生的绝对是一个实现细节,并且可能不太好依赖——至少在不调用某个您依赖 FTP 服务的特定行为的地方时是这样。
  • 我希望您不打算依靠文件大小不再变化来检测整个文件已完成传输。这完全忽略了任何错误情况,例如连接断开。
  • 使用stat() 的问题在于它只显示磁盘上的实际内容。如果磁盘驱动器缓冲,或者如果操作系统缓冲,则从stat() 返回的值将不是文件的实际大小,而只是文件实际写入磁盘的量。

标签: c unix ftp operating-system solaris


【解决方案1】:

stat() 调用将显示与ls 相同的内容,因为ls 使用stat()(或该系列中的类似函数)来显示文件大小和属性。

因此,对于所有常见的文件系统,stat() 将返回当前文件大小,该文件大小通常会在 ftp put 事务期间不断增长。

然而,FTP 服务器(甚至 FTP 客户端)可能会选择创建一个请求目标名称的空文件,将实际数据写入临时文件,并在传输后将此文件重命名为真实文件名完全的。在这种情况下,stat() 将返回大小 0。但这不是通常发生的方式。

【讨论】:

  • 精彩的答案!您是否碰巧知道 Solaris 10 上的 FTP 是否恰好以这种方式处理临时文件并重命名?
  • Solaris 10 FTP-Server 基于 WU-FTPd,应直接写入目标文件(无临时文件/重命名)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多