Force Re-Check Problem: Auto File move and file size wrong.

[gotanga]

Hi,

I have lots of problems. All stem from the accidental deletion of .torrent files and my attempt to recover my old state.

I have three folders: download, download_done, and tmp (for .torrent files). I accidentally removed tmp.

When uTorrent started up it complained about not being able to find .torrent files. fsck says i, what now? I went to the tracker where i had downloaded the original .torrents from and tried to re-create them. Odd things happened.

* If the file was originally in downloading mode (in download dir), it asked to update the trackers, but did not queue, because the torrent file did not exist, and was not recreated.

* If the file was seeding but had not been moved to download_done, same as above.

BTW this problem seems to happen mostly when seeds and downloads exists in the same folder. So what you get eventually is something like below, where a seed sticks to the download folder.

download/files/queued

download/files/seeded

download_done/files/seeded2

download_done/files/seeded3

* If the file was seeding but was in the download_done folder, then it starts a new download rather than checking for a seed in the download_done folder.

bugger says i, I would need to copy all of the seeding files from download_done/ to download/. Then i (in my naivete) thought, well what if i just save the torrent from the tracker, rename it to the missing uTorrent .torrent file in the error message, then i should be good to go!. I tried it, hit a force-recheck, and it seemed to work. This *seemed* to work. That was until i mixed up source and destination .torrent files. For example i copied the the downloaded seeded2.torrent file to tmp\seeded3.torrent, and hit a force-recheck.

This is of course wrong, But another unusual thing happened. The torrents that referred to a single file all changed their file size to the size of the file referenced in the wrong torrent. In this case from 800k to 250 meg. Ouch. So i copy the seeded2.torrent, and force a re-check. I still have a 250meg working pdf file that uTorrent is now seeding as if it is 800k. So copy the seed back to the download folder, i remove the seeded2.torrent, delete it from the uTorrent download queue, and try to re-download from the original tracker. The file gets checked and re-seeded at as a 250 meg file containing 800k of data. This problem is the same for 200meg files.

Presumably this is a bug in force-recheck, where it does not ensure the correct size the checked file?

Is there any way to fix it short of re-downloading?

update:

In the interest of science, i tried the same with a fully downloaded 400meg seeded2 file. The seeded2 was chopped to 250meg and queued to re-download the amputated data.

[jewelisheaven]

Don't do stupid stuff to your pathing or files.

The next time you happen to delete all your torrents, close uT. FIX the torrents, then load it back up. You avoid any and all messes you create by causing the ERROR state. As far as the filesize wrong... If the file is not the right file for the torrent, it will not check to 100%. uT does not truncate files afaik. If you have multiple torrents for the same file saying the file is a different size, it's not the same file.

Also your examples could use some work. Torrent1.torrent and Torrent2.torrent are different files and torrents in the main list, and as such reference different files. Unless you have a LABEL with Files and use "append label to directory" the path in your Preferences should be Download\Files\ .

[gotanga]

> Don't do stupid stuff to your pathing or files.

ok.

> The next time you happen to delete all your torrents, close uT. FIX the torrents, then load it back up.

How do i FIX the torrents in this situation?

>You avoid any and all messes you create by causing the ERROR state.

ok.

> As far as the filesize wrong... If the file is not the right file for the torrent, it will not check to 100%. uT does not truncate files afaik. If you have multiple torrents for the same file saying the file is a different size, it's not the same file.

This is not the quite case AFAIKT. I shall illustrate using what i hope is a better example.

This table is a summary of the states of the torrents in uTorrent before i removed the tmp directory and the .torrent files.

| Name | Size | Type | Referenced by | Prior Torrent State |

|-------+--------+-------+------------------+------------------------|

| file1 | 875k | zip | file1.Torrent | downloaded and seeding |

| file2 | 220meg | video | file2.Torrent | downloaded and seeding |

During my attempt at restoration, the process that caused the problem went something like:

- move file1.zip and file2.mpg to the "download" directory.

- start uTorrent.

- download the original tracker torrents files - downloadfile1.torrent & downloadfile2.torrent.

- rename downloadfile1.torrent & downloadfile2.torrent to the names required by uTorrent - file1.torrent & file2.torrent

- copy file1.torrent and file2.torrent to the tmp directory

- replace file1.torrent with file2.torrent.

- Make a "force recheck" to force uTorrent to deal with file1.zip as before - After recheck file1.zip had become 220meg and Queued for download.

- stop uTorrent and restore file1.torrent

- "force recheck" file1.torrent checks file1.zip is intact - reports it as 875k and Queued for seeding.

after that, file1 seeding information copied from my running uTorrent:

| Name | # | Size | Done | Status | Seeds | Peers | Down Speed | Up Speed | ETA | Uploaded | Ratio | Avail. | Label | Added On | Completed On |

| file1.zip | * | 875 kB | 100.0 % | Queued Seed | 0 (0) | 0 (0) | | | ∞ | 0.0 kB | 0.000 | 1.000 | | 25/04/2008 21:27:53 | |

Directory listing of file1.zip

---------------

d:\download>dir file1*

Volume in drive D is DATA

Volume Serial Number is 0000-0000

Directory of d:\download

25/04/2008 20:29 220,917,074 file1.zip

1 file(s) 220,917,074 bytes

0 Dir(s) 188,220,047,360 bytes free

zipinfo of file1.zip

----------------

> zipinfo file1.zip

Archive: file1.zip 220917074 bytes 18 files

-rw-rw-rw- 2.0 fat 5856 b- defN 5-May-92 18:37 file1/ANIM

-rwxa-- 2.0 fat 11471 b- defN 15-Jun-92 15:41 file1/DM.EXE

-rw-rw-rw- 2.0 fat 4938 b- defN 12-Mar-92 11:49 file1/EGA

-rw-rw-rw- 2.0 fat 364196 b- defN 25-Oct-91 19:40 file1/END

-rw-rw-rw- 2.0 fat 94779 b- defN 5-May-92 18:24 file1/FIRES

-rw-rw-rw- 2.0 fat 8151 b- defN 5-May-92 18:33 file1/IBMIO

-rwxa-- 2.0 fat 8724 b- defN 15-Jun-92 15:28 file1/INSTALL.EXE

-rw-rw-rw- 2.0 fat 15474 b- defN 5-May-92 18:36 file1/SELECTOR

-rwxa-- 2.0 fat 7585 b- defN 12-Dec-91 07:12 file1/STATS.EXE

-rw-rw-rw- 2.0 fat 7570 b- defN 27-Oct-91 06:41 file1/SWOOSH

-rw-rw-rw- 2.0 fat 4566 b- defN 27-Oct-91 06:09 file1/TANDY

-rw-rw-rw- 2.0 fat 12002 b- defN 28-Oct-91 16:56 file1/TITLE

-rw-rw-rw- 2.0 fat 4503 b- defN 5-May-92 18:33 file1/VGA

drwxrwxrwx 2.0 fat 0 b- stor 28-Oct-00 22:22 file1/DATA/

-rw-rw-rw- 2.0 fat 33357 b- defN 2-Dec-91 03:29 file1/DATA/FILE1.DAT

-rw-rw-rw- 2.0 fat 363417 b- defN 23-Feb-92 00:12 file1/DATA/GRAPHICS.DAT

-rw-rw-rw- 2.0 fat 162482 b- defN 26-Feb-92 01:05 file1/DATA/SONG.DAT

drwxrwxrwx 2.0 fat 0 b- stor 28-Oct-00 22:22 file1/

18 files, 1109071 bytes uncompressed, 894462 bytes compressed: 19.4%

If the process is repeated with a file1.zip larger than 220meg, then the first "force re-check" truncates the file1.zip to 220meg. When file1.torrent is restored, it resizes the file back to its original larger size, checks the first 220meg as ok, and queues file1.zip to download the truncated portion.

Note this only happens when the torrent refers to a single file, e.g. file1.torrent->file1.zip & file2.torrent->file2.zip. I suspect only it is only with the Prefs>Downloads>"Pre-allocate-all files" ticked. It may be that there is an assumed relationship between the <torentfile>.torrent and <torrentfile> due to filenames rather than what <torrentfile>.torrent may contain.

I guess there is no way to get uTorrent to re-size the file?

The other problem. This occurs all the time even without my screwing around. Using the directory "download" for queued downloads & "download_done" for queued seeds.

I download Torrent1.torrent, Torrent2.torrent and Torrent3.torrent as below:

Torrent1.torrent refers to these files:

folder\file1.mpg

folder\file1.nfo

Torrent2.torrent refers to these files:

folder\file2.mpg

folder\file2.nfo

Torrent3.torrent refers to these files:

folder\file3.mpg

folder\file3.nfo

Almost without fail, when all have finished and should be seeding from "download_done", there is one seeding from the "download" directory. Usually the last one to finish. A recheck does not cause it to move to "download_done", though that is the behaviour with most of the other seeding torrents that you force a re-check on.

Is there some kind of switch to force the move?

[jewelisheaven]

Once a torrent is moved that's it. I think the move operation is done as many times it's asked in 1.8. . .Unfortunately it worked for me when I tried it several times just now.

Regarding the truncation.. I have to admit I don't use pre-allocate. There's an easy way to check it though, turn it off. If you're rechecking prior to starting the torrent uT doesn't even open the file for writing yet... so I have to think it's due to the way you're accessing the file. Also GENERALLY there is a relationship between the torrent name and the files referenced. You see the file(s) in the INFO dictionary and most creators use the 'file/folder name' +'.torrent' but I guess that's not always the case when you're downloading them off the web.

As far as my point about the ERROR: status.... with uT closed you fix whatever you messed up with the folder. On re-open uT goes through the torrent list again. There's a rather easy GUI way to check torrent names/locations IMO, it's Ultima's Bencoded File Editor, and can be found @ http://forum.utorrent.com/viewtopic.php?id=31306 . What you're looking for is resume.dat (usually in %APPDATA%\uTorrent ) and each node/key you see below [ROOT] is a torrent file. The name of the key is the full path to the torrent according to uT.

[gotanga]

> Once a torrent is moved that's it. I think the move operation is done as many times it's asked in 1.8. . .Unfortunately it worked for me when I tried it several times just now.

I upgraded to 1.8, force recheck, no luck. Did you mean the a manual move of the torrent file(s) and folder(s) to download_done then changing the source information in the UI? Possibly the rorce-recheck move is a feature that could be added. I know this is something that azereus does.

> Regarding the truncation.. I have to admit I don't use pre-allocate. There's an easy way to check it though, turn it off. If you're rechecking prior to starting the torrent uT doesn't even open the file for writing yet... so I have to think it's due to the way you're accessing the file. Also GENERALLY there is a relationship between the torrent name and the files referenced. You see the file(s) in the INFO dictionary and most creators use the 'file/folder name' +'.torrent' but I guess that's not always the case when you're downloading them off the web.

Well what i noticed was that uTorrent would rename the torrent file to something like the target. So in the above example Torrent1.torrent, Torrent2.torrent and Torrent3.torrent would become file.torrent, file.1.torrent and file.2.torrent. This might be where the assumption is made...

> As far as my point about the ERROR: status.... with uT closed you fix whatever you messed up with the folder. On re-open uT goes through the torrent list again. There's a rather easy GUI way to check torrent names/locations IMO, it's Ultima's Bencoded File Editor, and can be found @ http://forum.utorrent.com/viewtopic.php?id=31306 . What you're looking for is resume.dat (usually in %APPDATA%\uTorrent ) and each node/key you see below [ROOT] is a torrent file. The name of the key is the full path to the torrent according to uT.

Thanks.

[jewelisheaven]

uT doesn't rename torrents. When an identical named torrent is loaded into it, the .# suffix is added. You see what corresponds to what when viewing resume.dat with a capable editor.

Force recheck does not work when the actual location the data is at is at-odds with the General "Save As" field. That's why force recheck doesn't work. I remember moving multiple times works when re-completing torrents. however that requires it to be pathed correctly, or already being downloaded in the default save directory (if only move from default directory is checked).