【问题标题】:Resuming a large file write in Python在 Python 中恢复大文件写入
【发布时间】:2010-07-26 02:00:56
【问题描述】:

我有一个大文件传输(比如 4gb 左右),而不是使用shutil,我只是以正常文件方式打开并写入它,这样我就可以在它移动时包含一个进度百分比。

然后我想到尝试恢复文件写入,如果由于某种原因它在此过程中失败了。虽然我没有运气。我认为这将是抵消源文件读取和使用搜索的巧妙组合,但到目前为止我还没有运气。有什么想法吗?

此外,是否有某种动态方法来计算读写文件时使用的块大小?我对该领域相当陌生,只是阅读以使用更大的文件来获取更大的文件(我目前使用的是 65536)。有没有一种聪明的方法可以做到这一点,或者只是猜测..?谢谢大家。

这里是附加文件传输的代码sn-p:

                newsrc = open(src, 'rb')
                dest_size = os.stat(destFile).st_size
                print 'Dest file exists, resuming at block %s' % dest_size
                newsrc.seek(dest_size)
                newdest = open(destFile, 'a')
                cur_block_pos = dest_size
                # Start copying file
                while True:
                    cur_block = newsrc.read(131072)                    
                    cur_block_pos += 131072
                    if not cur_block:
                        break
                    else:
                       newdest.write(cur_block)

它确实会追加并开始写入,但它会在末尾写入 dest_size 更多的数据,原因可能对你们其他人来说是显而易见的。有什么想法吗?

【问题讨论】:

  • 文件传输出了什么问题?
  • 你能告诉我们你尝试追加到文件吗?您应该能够寻找并继续写作。您是否使用文件模式“a”打开?
  • 文件传输并没有真正出错。但是,当我开发此代码通过网络移动 6+gb 的文件时,很高兴能够启动它以观察新的变化,并让它在大文件传输中从中断的地方继续。我已将代码附加到操作中。
  • 我也会使用b 模式打开目标文件,只是为了保存(虽然我不认为这是你的问题)。

标签: python file-io resume


【解决方案1】:

对于您问题的第二部分,数据通常以 512 字节的块从硬盘驱动器读取和写入。因此,使用倍数的块大小应该可以提供最有效的传输。除此之外,没什么大不了的。请记住,您指定的任何块大小都是 I/O 操作在任何给定时间存储在内存中的数据量,因此不要选择太大以致占用大量 RAM 的数据量。我认为8K(8192)是一个常见的选择,但64K应该没问题。 (当您选择最佳块大小时,我认为正在传输的文件大小并不重要)

【讨论】:

  • 操作系统之间通常有一层缓冲,因此即使您使用的东西不是 512 的倍数,它也可能无关紧要。但是尝试不同的块大小是微不足道的,如果你想确定的话,可以自己进行基准测试!
猜你喜欢
  • 2015-03-01
  • 1970-01-01
  • 1970-01-01
  • 2011-06-10
  • 1970-01-01
  • 1970-01-01
  • 2016-06-04
相关资源
最近更新 更多