1

我使用truncate文件来检查我的软件在不完整文件上的行为，结果完全出乎意料。我开始挖掘并最终来到这里。

>cp full truncated
>truncate -s 2485129215 truncated
>ls -la
-rw-r--r-- 1 yuki yuki 2485129215 Mar  6 14:30 truncated
-rw-r--r-- 1 yuki yuki 2485129216 Mar  6 14:24 full

我希望这truncated与full没有最后一个字节的情况相同。但不是，我跑xxd了这些并比较了diff- 很多千兆字节的差异，很难理解。

我用python写了一个哑字节比较程序。

import os
f1 = open('./full', 'r')
f2 = open('./truncated', 'r')

s1 = os.stat('./full').st_size
s2 = os.stat('./truncated').st_size

print('size1 {}'.format(s1))
print('size2 {}'.format(s2))

s = min(s1, s2)

print('min={}'.format(s))

i = 0
while i < s:
    b1 = f1.read(1)
    b2 = f2.read(1)
    if b1 != b2:
        print("{} {:02x} != {:02x}".format(i, ord(b1[0]), ord(b2[0])))
        break
    i += 1

返回

size1 2485129216
size2 2485129215
min=2485129215
1288204320 44 != e8

好的，试着看看xxd

>xxd -o 1288204320 -l 5 ./full
4cc87020: 2a00 0000 00                             *....

看起来不像...运行这个

>xxd -o 1288204319 -l 5 ./full
4cc8701f: 2a00 0000 00

严重地？为什么看起来和之前的一模一样？

linux工具有什么问题，或者我使用它？我在常规的 Ubuntu 18.04 上。会不会是truncateandxxd只接受某种低数字而溢出？有任何想法吗？

顺便说一句，运行head -c 2485129215 full > truncated给出了预期的结果。万岁！至少有些东西确实有效。

4

0 回答 0