Question

我目前正在尝试写入预先分配文件的不同位置。

我首先像这样分配了我的文件：

File.open("file", "wb") { |file| file.truncate(size) }

大小是文件的总大小。

之后，我收到了适合该文件的Y位置的XX大小的数据。请记住，这部分过程是分叉的。每个fork都有自己独特的套接字，并打开它自己独特的文件句柄，写入文件，然后关闭它。

data = socket.read(256)

File.open("file", "wb") do |output|
   output.seek(location * 256, IO::SEEK_SET)
   output.write(data)
end

这应该允许分叉进程打开文件句柄，寻找正确的位置（如果位置是2，data_size是256，那么写入位置是512 - > 768）并写入数据块收到了。

虽然这样做是我无法理解的。我监视文件大小，因为它正在填充，并且它从不同的文件大小中弹跳，不应该改变。

使用十六进制编辑器分析文件时，文件数据标题应位于顶部，并填充nullbytes（与文件的1/4一样明智）。虽然如果我将分叉进程限制为仅写入1个文件块然后退出，则写入正常并且位于正确的位置。

我做了一些其他的测试，例如转储部分位置，数据的起始位置以及寻找文件正确位置的公式似乎也是正确的。

这里是否有我缺少的东西或是否有其他方法让多个线程/进程打开文件的文件句柄，寻找特定的位置，然后写一大块数据？

我还尝试在文件上使用FLOCK，它产生相同的结果，同样使用主进程而不是分叉。

我已经测试了相同的应用程序，但是每次我需要快速连续写入数据（传输接近70mb / s）时打开/关闭文件句柄，我为每个分叉进程创建了一个文件句柄并保持打开状态。这解决了导致与匹配校验和重复文件1：1的问题。

所以问题是，为什么快速连续打开/写入/关闭文件句柄导致这种行为？

Answer 1

这是您的文件模式。

File.open("file", "wb")

＆＃34; WB＆＃34;表示＆＃34;打开时，将文件截断为零长度＆＃34;。

我建议＆＃34; r + b＆＃34;，这意味着＆＃34;阅读和写作，没有截断＆＃34;。在此处阅读有关可用模式的更多信息：http://ruby-doc.org/core-2.2.2/IO.html#method-c-new

顺便说一下，＆＃34; b＆＃34;在那些模式中意味着＆＃34;二进制＆＃34; （而不是默认＆＃34; t＆＃34;（文本））