One torrent keeps rechecking itself on startup?

[ghost]

I have this one torrent that would keep rechecking itself whenever I start up qbittorrent. It's ~13 GB, and I have no idea why it does that. Anyone know why or have a solution to it?

[chrishirst]

This is for bug reports, you need to post the question at the support forum http://qbforums.shiki.hu/

Please include the version of qBT you are running AND your operating system along with any other relevant data.

[sledgehammer999]

As said, I need qbt version and OS.

[Belove0]

I'll suggest one circumstance that this can occur on Windows operating systems:

If the total path+filename length of any file in the torrent is greater than Windows' normal maximum path length of 255 characters.

qBT supports longer paths in some places.. For example, it will successfully recheck a torrent containing longer paths and successfully seed the same torrent. However, there are many places where qBT does not support longer paths, including when it checks the resume data at startup. I believe I have seen "Mismatching file date/time" (or however it's phrased) errors in this circumstance, and then the torrent is automatically rechecked. If the files are not corrupt, it will check out to 100% every time, despite the long paths. The error can be confusing.

Long paths will nonetheless cause problems in most Windows applications and you cannot access them correctly in Windows Explorer itself, so it is best to work within this Windows limitation. Counted in the path length is the drive letter, colon, all backslashes between folders, and the dot before the file extension.. i.e., everything is counted.

If this is the issue you may want to rename the folders containing the torrent to be as short as possible. You can count the characters to deduce if this is the issue at hand as well.

[ghost]

That's exactly the problem ^

I remember copy pasting the torrent and the torrent won't move some of the files due to it being too long.

Thanks

[sledgehammer999]

Why did you close this.

@UnrestrictedMind @AsaRossoff
Do you have any torrent that you can link to? This would be interesting for libtorrent to fix...

[Belove0]

@sledgehammer999, to replicate, you can use any torrent.
Here's one small example: http://download.documentfoundation.org/libreoffice/src/4.2.5/libreoffice-help-4.2.5.2.tar.xz.torrent

When adding the torrent, in some cases qBT may catch the issue and prevent adding the torrent... but it is not correct in all circumstances... this part I am vague on as I have not experimented with the issue in the AddTorrent dialog in some time. I know it makes mistakes about path length when the add .!qb option is selected (letting long paths slip through which will download fine but cannot be renamed to non-.~qb on finish, making the torrent seed incorrectly or redownload files). It may also make mistakes about pathlength in torrents with subfolders.. But honestly, I am vague on the Add Torrent part right now.

If you add any torrent though, I believe you can rename folders and files in the torrent to exceed the path length. I'm sure you can relocate the torrent to exceed the path length.

So one way to replicate I think is to add any torrent, then "Set Location..." to to a path you've created with close to 255 characters in it and a file in the torrent with any file in it whose name will take the total pathlength to over 255 characters. e.g. ~~

• This worked from Windows 7 command prompt:

md "C:\456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 100"

md "C:\456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 100\23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 200"

md "C:\456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 100\23456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 200\234567890123456789012345678901234567890123 247"

md C:\temp123

• Then I added the torrent http://download.documentfoundation.org/libreoffice/src/4.2.5/libreoffice-help-4.2.5.2.tar.xz.torrent to "C:\temp123" in a paused state.
• Then I used Set Location... to move the torrent to the 247-character path.
• Then I started the torrent. Moments later it finished downloading successfully to this extra-long path.
• Then I Quit qBT and waited for the process to exit in task manager and restarted.
• Error Log:
  - Fast resume data was rejected for torrent libreoffice-help-4.2.5.2.tar.xz, checking again...
- Reason: libreoffice-help-4.2.5.2.tar.xz fast resume rejected: mismatching file size
• It was rechecked (since this file was so small I was unable to observe it -- it happened before the GUI responded)
• It automatically resumed seeding.

P.S. I ran into some other interesting issues developing this test case: (1) I was able to select this long path in the Add Torrent dialog, but the path showed up, after selection, using deprecated shortnames, something like "C:\4567891\2345671\234567~1\libreoffice-help-4.2.5.2.tar.xz". Set Location however always returned the long name for the folders. I believe the shortnames only existed in this case because I created the directories at the command prompt and at least in Windows 7, are not created by Explorer by default. Ever since the advent of long filenames, the generation of shortnames could be disabled in Windows anyway, and were not created in all circumstances regardless. (2) I found several issues with using Set Location with these long paths, where relocating the torrent after selecting a long path to another level within the long/longish path actually resulted in the entire long path set of folders being deleted from disk (even though the path was successfully selected.)

My ideal would be for qBT and libtorrent to enable long path (> 255 character) support everywhere, honestly. Even though there will be issues in Windows Explorer and many applications, it will be a simple way to eliminate several bugs related to inconsistent handling/checking of path lengths in qBT/libtorrent. A user can remedy the issue later if needed by renaming folders in Windows Explorer to shorter names or various other methods, or work around them by creating symbolic links or junctions that are equivalent short paths for accessing the files in other applications. This way qBT does not have to check path lengths in many different places in its code, accounting for planned moves of files (if enabled), the !qb extension, and, whenever a user renames a part of the torrent, checking every child-fileobject path length, etc.

Related but separate regarding what I do as standard practice: I frequently use detailed, longer folder names and so have had to find ways to work around this issue.. I use junction points now, but the AddTorrent dialog unlinks junction points when they are selected as download location (I need to report this issue separately but have not done so yet). The AddTorrent dialog also lists a trailing backslash as part of the location of the torrent, and today I discovered, seems to use shortnames if they exist on disk. In contrast, Set Location works with junction points fine, uses the exact long path name, and does not show a trailing backslash as part of the torrent location. I now Add torrents with an invalid path as default and use Set Location to set the junction point that I want it saved in, and then rename any folders in the torrent if needed (if I rename the folders before setting the location, the renamed foldername will not be used on disk although qBT shows it in the torrent data). I have tried changing the NTFS permissions on one of my junction points to try to prevent qBT/libtorrent from unlinking it, but I have not gotten around to testing it yet.. and it would only be helpful as a different workaround anyway. I'll report these other issues separately in time... I have a lot going on right now and want to be able to attend to any questions or testing asked of me properly.

[FranciscoPombal]

qBittorrent now supports long paths on Windows (requires Windows 10 1607 or more recent).