Error:

Ktorrent opaquely deleted several GB of a completed torrent when activating it for seeding.

Requested fix:

For misplaced torrents/parts, try searching a user-selected directory tree for missing parts.
Clearly label actions which will delete torrent data files.

Scenario:

I had some torrent data directories, <foo> in my home directory, ~me, which is messy to begin with and certainly didn't need stray torrents hanging around.

So, I moved ~me/<foo> to ~me/<new>/<foo>. (I'll drop the ~me bit now, just assume everything is relative to ~me.)

I then cranked up KTorrent, which complained that it couldn't find <foo> . I expected this, but I also expected an easy way to say "Hey, look over here". I couldn't find one, so I just created a symlink from <foo> to <new>/<foo> and it was happy with that torrent. KT Kept complaining about the others, but I just ignored the problem for the momemt.

Symlinks being no better than directories, I found .kde/share/apps/ktorrent/tor*/stats and sed(1)ed OUTPUTDIR from <foo> to <new>/<foo> . No joy.

Mucked about a bit with the File | Import option, but wasn't going to manually select 20-odd torrent/dir pairs. Played with some context menu ("right click") options:

Set DL Location: Opens previous dialog position
Open "data" dir: Opens <new>/<foo>


Later, noticed seeding was broken as well. Started a seed file, got the same message:


Code: Select all

 Several data files of the torrent <foo> are missing.  Do you want to re-create them,  or do you want to not download them.



Thinking KT wouldn't mess with completed files, I figured the worst case for "re-create" would be duplicates. Unfortunately, that was a bad assumption, as all the torrent's files went away. From <new>/<foo>

I usually just delete de torrent and reopen it when I move my stuff around. When the client asks me where to save them I point it to the new directory and its done.

However, now that you mentioned it I'll take the time to write about something that happened yesterday. I had some torrents going in azureus while the guys at a private tracker removed ktorrent from the banned list. Anyway, as I finally got to ditch azureus I opened the torrent in ktorrent and pointed it to the right directory. However, there was a problem. I didn't want the torrent to start right away and I didn't want to download many of the files within the torrent either. So I just instructed ktorrent to not download any by deselecting them all from the list (in the initial torrent opening within ktorrent). I figured this would just let the files I already had be or maybe even check them to see if they were available... no such luck. Ktorrent deleted them all without a peep.

I don't usually complain about these things, yknow live and learn but since you started the thread I guess its a more widespread problem than just my own mistake.

In my scenario a proper behavior for the client would've been to just ignore the files instead of deleting them.

Right click on torrent -> Set download location -> Select new location

Maybe I should rename this option to "Move the **** data" ?

Btw, if you start messing around with stats files, don't be surprised to get burned.

George wrote:Right click on torrent -> Set download location -> Select new location

Maybe I should rename this option to "Move the **** data" ?

How about a "Go find my ****ing data" option? Seriously, it's not a bad piece of functionality to be able to bulk-import torrents laying around, no?

George wrote:Btw, if you start messing around with stats files, don't be surprised to get burned.

I wasn't surprised - breaking encapsulation is never a good thing. I was disappointed it nuked valid data files without saying it was going to do so...

Perhaps I'm mis-understanding the philosophy here:

To me the data in "MyPr0n_Part001.mpeg" (et al.) is a "torrent", while MyPr0n.torrent is the metadata that lets be find and validate MyPr0n. Since I am a famous performer, many people have copies of the "MyPr0n" files. This is good until some goofball renames a file "MyPr0n_Part607-MidgetsAndDonkeys.mpeg" just because that's her "thing". [1]

Now there are two pointers to the same data. I would think one of the core functions of a BT client would be to search out and take advantage of these duplications.

Am I crazy?

Thanks,
-Greg

[1] This is directly analogous to the problem a *ix-ish file system has with dentrys and inodes, where the dentry(s) is/are the fs/torrent name(s) and the data itself ius the inode.

GregJ wrote:

George wrote:Right click on torrent -> Set download location -> Select new location

Maybe I should rename this option to "Move the **** data" ?

How about a "Go find my ****ing data" option? Seriously, it's not a bad piece of functionality to be able to bulk-import torrents laying around, no?

The problem with this is that, we currently don't support moving single files of a multi file torrent, once this is added we can add a feature for you to select the new location of the files.

Perhaps I'm mis-understanding the philosophy here:

To me the data in "MyPr0n_Part001.mpeg" (et al.) is a "torrent", while MyPr0n.torrent is the metadata that lets be find and validate MyPr0n. Since I am a famous performer, many people have copies of the "MyPr0n" files. This is good until some goofball renames a file "MyPr0n_Part607-MidgetsAndDonkeys.mpeg" just because that's her "thing". [1]

Now there are two pointers to the same data. I would think one of the core functions of a BT client would be to search out and take advantage of these duplications.

That will all be possible when we add the feature to move individual files of a torrent.