python读取linux文件最后一行,python文件读取损坏文件的行（macosx），而不是Linux...

我继承了一些代码，这些代码可以读取大量的数据文件，并将这些数据打包成块，然后发送到某个服务器并继续运行。在

有时打包程序失败/死亡/无法联系服务器，等等，数据文件会变大。在这一点上，很少有执行所有这些操作的小ArchLinux机器无法完成这个过程-此时，我获取数据并在Mac上本地执行相同的任务(同时为了获得更好的解决方案)。在

ArchLinux机器从来没有像我的Mac经常遇到的那样的错误，这就是：

问题是，在Mac上，这最终会将一些行粉碎在一起。得到的列表是1000长，但至少其中一行实际上是一行的串联，没有\n，而另一行的大部分从一个小的方向向上(36行后退，在本例中，正好是4096个字节)文件(这在文件向后读取时有一定意义，见下文)。在

查看文件seek()和tell()在islice之前和之后的位置，我分别得到3530855和{}，读取大小为120832字节。在

如果我在pdb中遇到这个错误时，将文件返回到3530855，然后file.readlines(120832)我得到1092行(readlines'的大小只是一个提示，所以有意义)，并且munged行不存在(但是它的组成部分在各自正确的索引中是完整的)。在

另一个进程在写的时候，也不会被分流。在

反向读取器(生成器)到达islice之前的第一个tell()的位置，上面给出的3530855是由一个向后读取器(生成器)到达的(文件是os.dup()'d，首先在生成器内部)yield的一个循环，当它发现一个包含它成功发送的最后一个时间戳的行时，break上的一个循环：for line in BackwardsFileReader(fp):

if somecondition:

break

以及

^{pr2}$

如果我不费心将文件隔离，并在Mac上读取整个文件，问题仍然会发生，但不会发生在同一个地方，而且频率也会降低。在

我唯一能想到的是生成器可能会将文件进一步向后推进(4096字节，缓冲区大小)，而islice正在向前读取文件。。。奇怪的是，这在Linux机器上从来没有发生过。低级文件操作不是我的面包和黄油，当我在这里与一个生成器结合时，我想我一定遗漏了一些东西——有人能在这里建议下一个调试步骤吗，或者提供一个关于什么可能导致这种差异的提示吗？在