Open GoogleCodeExporter opened 8 years ago
See https://github.com/qbittorrent/qBittorrent/issues/632
Original comment by zhang8...@gmail.com
on 5 May 2013 at 4:30
how do you move file A?
Do you call torrent_handle::rename_file()?
If you just move it directly at the filesystem level, how would you expect
libtorrent to know that it was moved, and where to find the data stored in it?
Original comment by arvid.no...@gmail.com
on 5 May 2013 at 8:36
just cut and paste A to another folder. No complicated things.
Original comment by zhang8...@gmail.com
on 5 May 2013 at 8:38
because I marked it as "Do not download" and the libtorrent is stilling trying
to read/write on this file. That's a bug.
Original comment by zhang8...@gmail.com
on 5 May 2013 at 8:39
of course after I "force recheck files". The problem is gone. However, it
should not perform like this.
No windows based torrent program has such problem. So you should not either.
Original comment by zhang8...@gmail.com
on 5 May 2013 at 8:41
but "do not download" does not mean "do not upload".
I'm quite certain than all, or at least most, bittorrent clients would behave
the same.
Would you expect libtorrent to always stop uploading files that are marked as
do-not-download, or would just just expect libtorrent to allow such files to
disappear? What about the edge pieces that are required to complete the
adjacent files?
Original comment by arvid.no...@gmail.com
on 5 May 2013 at 9:32
OK. Now I understand libtorrent's logic.
However, just one thing:
Windows program Bittorrent does NOT have such problem, when marked as "do not
download", of course it is also "not upload". The reason is simple: where to
find the data for not-downloaded files?
I DO think you should perform the same way. The Bittorrent never has such
problem so I think they well fixed the adjacent pieces. You could, as well.
Original comment by zhang8...@gmail.com
on 5 May 2013 at 9:38
Just because a file is marked as do-not-download doesn't mean you don't have
any data in that file.
You may for instance download the entire file, or part of it, before you mark
it as do not download. If you have half of the pieces in the file when you mark
it as do-not-download, those pieces will obviously still be seeded. This is
certainly the case in uTorrent and BitTorrent mainline, and I would expect any
quality bittorrent client to behave the same.
It's also possible to download to files even after they have been marked as
do-not-download. If and adjacent file is marked for downloading, and the first
or last piece in it overlaps with the file set to not download, that partial
piece is still downloaded, even though it belongs to the file selected to not
be downloaded. This is because in order to verify integrity of the piece, and
in order to be able to seed it, you need the whole file.
uTorrent does this as well. However, those partial pieces are placed in a
partfile and not in the actual file itself. But this ticket is about moving
files away from under the feet of the client.
Original comment by arvid.no...@gmail.com
on 5 May 2013 at 9:53
Whatever, the I/O error needs to be removed otherwise the software performs
like buggy to users.
Maybe you can perform a "force recheck files" automatically before you throw
out "I/O error"?
Original comment by zhang8...@gmail.com
on 5 May 2013 at 9:56
I would guess BitTorrent did the "check" automatically so the problem is not
noticed by users.
Original comment by zhang8...@gmail.com
on 5 May 2013 at 9:58
Original issue reported on code.google.com by
zhang8...@gmail.com
on 5 May 2013 at 4:29