arvidn / libtorrent

an efficient feature complete C++ bittorrent implementation

Home Page:http://libtorrent.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

checking an existing file with some ending bytes

Lwxiang opened this issue · comments

libtorrent version (or branch): 1.2.19
platform/architecture: x86_64
compiler and compiler version: gcc7.3.1

I have a file existing on my disk, then I use libtorrent to download a new file which leaks some bytes at the ending of file.
for example, file1 is on my disk, which's hexdump is like

0000000: 6865 6c6c 6f20 776f 726c 640a 0a20 0a    hello world.. .

then I try to download file2, which's hexdump is like

0000000: 6865 6c6c 6f20 776f 726c 640a 0a    hello world.. .

file2 leaks 20 0a two bytes at the ending of file comparing with file1.

Here is the problem, when I add the file2 metadata into libtorrent, libtorrent start file checking, and check the size(file2) piece data, and it find all data is correct and completed, then the torrent's state changes to seeding. But the file on disk is still file1, not file2, it still has the ending 20 0a. The whole progress never call writev to the disk, all actions is about reading and hashing.

Obviously the file should be resized to the correct size even when all piece data done hashing.

file1_dump

0000000: 6865 6c6c 6f20 776f 726c 640a 0a20 0a    hello world.. .

run xxd -r file1_dump file1 can produce the file1

file2_dump

0000000: 6865 6c6c 6f20 776f 726c 640a 0a    hello world.. .

run xxd -r file1_dump file2 can produce the file2

and this testcase and reproduce the problem.

What will happen if there is no extra byte in the end: if you remove 0a does the bug still happen? Also you didn't tell us what happens if you actually seed that file. Can you fully reconstruct it?