seeding missing files

[skyrma]

There is a torrent with availability 99.9%, because one file isn't completed and some are missing. I have downloaded those files from different source (FTP) and I would like to make BitComet to see them as finished, so that I could seed those missing part.

How can I do this? Overwritting and copying missing files doesn't help, BitComet still see it like incompleted. :unsure:

[Soraiya]

Hm, this is kind of hard...because with the !bc extensions as well as various other functions, clients can get confused with the file contents.

Have you tried copying the exact filename of that 'missing' file to the file that you downloaded separately via FTP?

[skyrma]

Actually I'm not using !bc extension for incomplete files. It seems that client is storing torrent progress and other run-time data somewhere else. Maybe by clearing it, client will restore progress status from downloaded files using hash info?

[Ashira]

If I'm getting this correctly, you are trying to copy files you've downloaded into the directory where the contents of a torrent is being downloaded and then making bitcomet detect that those files you've copied there have already been downloaded. Is this correct?

If so, if you add new data to a torrent, like copying a completed file that is part of it, then do a hash check. Bitcomet will check what parts of the torrent is complete and then continue downloading/seeding. It should detect the new "data" that you've copied into it, assuming that it is the correct file.

[skyrma]

If I'm getting this correctly, you are trying to copy files you've downloaded into the directory where the contents of a torrent is being downloaded and then making bitcomet detect that those files you've copied there have already been downloaded. Is this correct?

If so, if you add new data to a torrent, like copying a completed file that is part of it, then do a hash check. Bitcomet will check what parts of the torrent is complete and then continue downloading/seeding. It should detect the new "data" that you've copied into it, assuming that it is the correct file.

Yes, you are correct.

It's funny, but even after re-hashing it is not recognized as 100% completed files! :angry:

And rollsback to previous status... I don't get it... New files are REALLY completed and correct. I know it because checksum with sfv says all files are ok.

Any ideas?

Many thanks.

[The UnUsual Suspect]

hi,

Are you sure that the second source is in fact the same files as the torrent?

If they are, and you are using a router, then you should read here...

http://www.azureuswiki.com/index.php/Torre...p_at_99_percent

Suspect

ps. you might try removing the torrent, then restarting it, chosing the location of the complete files as save location, then it should hash the files, counting to 100% then start seeding. By this, I mean don't add to the location where they were being stored by your client, rather a separate loacation where the complete download was saved. If it then starts downloading, then the files are NOT a match.

[kluelos]

When a torrent is created, it stores a SHA-1 hash of all of the files within the torrent. This means that, if you try to replace one of the files in the torrent with another file, it must not only have the same name, it must be an exact binary duplicate of the file to be replaced. Even a "minor" or "unimportant" or even "trivial" difference will cause it to be rejected as an incorrect file, so bittorrent will ignore it and continue to try downloading the correct one.

The new file must be a byte-for-byte exact replacement of the old, probably including the file creation and last-modified dates. Otherwise it won't work.

This is a good thing. We all want bittorrent to work this way. So do you. Think about it.

[Const2k]

To kluelos:

When a torrent is created, it stores a SHA-1 hash of all of the files within the torrent.

[skipped by Const2k]

The new file must be a byte-for-byte exact replacement of the old, probably including the file creation and last-modified dates. Otherwise it won't work.

.torrent stores "all 20-byte SHA1 hash values, one per piece" not per each file - from BitComet's Wikipedia

File attributes (and even its name and extension) aren't related with either CRC32 (as in .sfv file) or SHA-1 algorithms and results they provide. That's why hashing is widely used in eDonkey2k, Direct Connect and other networks for searching needed file.

To skyrma:

Recently I've got the same problem. I just copied complete files to the directory I was downloading torrent to, deleted incomplete (.bc!) ones (on stopped torrent), checked hash in BitComet manually and started seeding. Everything went OK. My case was easier, as files I was working on had CRC32 included in their names (you know, these "...[A1B2C3D4]" things there), so I've just recalculated them with external program (namely, Hex Workshop) to make sure files are unmodified. Basically, BitComet makes the same, just in another way.

So I have "good faith belief" (as they say %) ) that your files are different. Though altering 100's of bytes in video or audio files may be unnoticeable to user, but even 1 bit change makes BitComet think the files aren't the same (as kluelos said).

Nevertheless, your idea was right, just some bad luck didn't let you use it.

[kluelos]

.torrent stores "all 20-byte SHA1 hash values, one per piece" not per each file - from BitComet's Wikipedia

I was wondering about that even as I typed it, but that WOULD make a helluva lot more sense, because it would be necessary anyway, and would guarantee the result. Thanks!

File attributes (and even its name and extension) aren't related with either CRC32 (as in .sfv file) or SHA-1 algorithms and results they provide. That's why hashing is widely used in eDonkey2k, Direct Connect and other networks for searching needed file.

As far as searching, I got that, but searching isn't really germane. But I did think the file data was hashed within the torrent itself. It isn't?

Nevertheless, your idea was right, just some bad luck didn't let you use it.

Nah, this is good luck. You don't want people to be able to do this. You were trying to do it for a good purpose, but if it can be done for good, it can be done for evil. If I can change a file in a torrent and have the swarm pick it up and spread the change, then I've got a great way to spread my new trojan or virus tracelessly. (No log of which piece I got from whom.)

[Const2k]

But I did think the file data was hashed within the torrent itself. It isn't?

Oh man... I've just finished posting something about this, so, please, read here. ("Not at all", to sum up :) )

*edit* Someone english-speaking, please tell me whether "not at all"="absolutely not" or "partially yes, partially no". I was using second one when I said this... You see, in Russian that would be "sovsem ne" and "ne sovsem", respectively :)

Nah, this is good luck. You don't want people to be able to do this. You were trying to do it for a good purpose, but if it can be done for good, it can be done for evil. If I can change a file in a torrent and have the swarm pick it up and spread the change, then I've got a great way to spread my new trojan or virus tracelessly. (No log of which piece I got from whom.)

You would have hard time changing the torrent's piece so that its SHA-1 remains the same :)

I was talking about idea of getting files that are impossible to find with BitTorrent from another sources (like FTP, in this case) - the SAME files - and putting them into existing torrent to let people finish their torrents.

I know what I'm speaking of - e.g.first file in multi-episode anime torrent was .sfv, the rest were just episodes' .avi's; nobody could get the piece that f**king .sfv was in, so episode next to it was impossible to download. I took the beginning of it from FTP, pasted it with Hex Editor, and seeded this single episode of long dead torrent.

(just some side-story, pardon me :) )