java - 在什么情况下，c 的 write() 函数写入的数据可能少于请求的数据？

Question

我正在以大约 10b 到 16000b 的 block 写入一个文件，突然每个 block 在大约 4050 字节处被截断(具体来说，依次为 4050、4051 和 4074 字节)。这意味着后续写入将覆盖本应写入的数据，从而弄乱我的数据。 4050b 以下的任何 block 都写得很好。

不幸的是，我无法重现它。我只有乱七八糟的文件，所以我正在调试寻找会导致这种情况的原因。

调试它，我意识到 c 的 write() 函数在后台被调用(这是 Java 代码，FileChannel.write()，但是标准库调用 c 的 write 并且只检查写入的字节 > 0)，并且它的文档不保证它会写出所有要求的数据，只是它会告诉你写了多少。

我不检查在 Java 领域写回的字节(但我确实知道，函数签名几乎完全相同)，所以修复非常简单。但是，由于我无法重现这一点，所以我不知道我是否已经解决了实际问题。因此，我希望某些 C 大师可以告诉我，要么我在吸食可卡因，要么在合法情况下 write() 一次无法写入超过 4050 个字节。

这是在 64 位 Linux 内核版本 3.0.0-26 上运行。

编辑:根据以下评论展开:

我正在写入一个普通的文件系统文件。我不确定在这种情况下非阻塞意味着什么，我没有使用回调或其他任何东西，但并没有为每个 block 明确地告诉操作系统刷新到磁盘。使用 Java 的 RandomAccessFile，“rw”模式打开文件。

Answer 1

来自 man 2 write:

   The number of bytes written may be less than  count  if,  for  example,
   there  is  insufficient space on the underlying physical medium, or the
   RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)),  or  the
   call was interrupted by a signal handler after having written less than
   count bytes.  (See also pipe(7).)

来自 man 2 setrlimit:

   RLIMIT_FSIZE
          The maximum size of files that the process may create.  Attempts
          to extend a file beyond this  limit  result  in  delivery  of  a
          SIGXFSZ  signal.   By default, this signal terminates a process,
          but a process can catch this signal instead, in which  case  the
          relevant  system  call  (e.g., write(2), truncate(2)) fails with
          the error EFBIG.

可以使用以下命令查看这些限制:

ulimit -Sf
ulimit -Hf

或者使用这个 C 程序:

#include <stdio.h>
#include <errno.h>
#include <sys/resource.h>

int main()
{
    struct rlimit rl;
    if (getrlimit(RLIMIT_FSIZE, &rl) == 0) {
        printf("%d %d\n", rl.rlim_cur, rl.rlim_max);
    } else {
        fprintf(stderr, "error: %d\n", errno);
    }
    return 0;
}