Let's move on. I don't misunderstand in any way. It doesn't pertain to the proposal. Instead it pollutes this topic and the tone of the topic.
I request that further comments be limited to the topic's proposal.
I not only welcome comments about the proposal, I've posted here because I am really interested in a cooperative discussion of the proposal, and any ideas people have about it. So, I hope no one is discouraged from commenting, even to criticize the proposal constructively, which I welcome as readily as any other relevant thoughts.
Short answer: qbt/libtorrent actively checks for files existence.
It could be made to ignore paused torrents but it isn't a simple thing to code. And honestly, I cannot be bothered implementing it at the moment.
All other discussion is irrelevant.
I completely appreciate you must have your priorities, and you are virtually the only active developer, part-time (it's amazing what you are doing for this project).
Thanks for confirming the behavior and where this (doesn't) lie(s) in your priorities, and explaining that it would not be a simple change.
Obviously you are free to and even must choose your priorities, and make design and implementation decisions.
I also appreciate that you ask for feedback on many things and your communication skills.
And that you, like all contributors, are at least mostly volunteer.
The libtorrent docs specify that libtorrent already handles some I/O errors with an auto-recovery mechanism, specifically named, I think, is the case of trying to write to a full disk (although the word is a bit vague).
Also, although it may be an advisable optimization to avoid checking for files with paused torrents (I don't know the reasons for it), I would actually like all files/filepaths that disappear to have a manual or automatic recovery mechanism when, perhaps, all that torrents' expected files are accessible again and match the normal checks -- not just paused torrents. That would not just help in cases like mine, but in other cases, as I described, as well, making many a "shucks, my network file server rebooted unexpectedly during seeding again"/etc. person's day a lot better.
If this mechanism is applied across the board for torrents, might most of the implementation then be in libtorrent, and possibly even simpler?
I'm not particularly trying to convince you to reprioritize this, I just want to flesh out what general implementation obstacles might be and then propose the appropriate things here (until someone wants to work on it, assuming it is acceptable) and/or to Arvid/libtorrent.
[quote="ciaobaby"]
On BT clients that use the $Partfile.dat convention for unwanted pieces the is only a single 'file' that holds the unwanted pieces.
[/quote]
Suggestions about moving to a single file for unwanted pieces has been out there for a long time, unfortunately I do not think it will be possible to implement w/o overriding libtorrent internals of storage_interface.
[quote="ciaobaby"]
Because the disc filing system has to call them something, try opening the file and you will find that it is ONLY the first few or the last few bytes that are actually there.
[/quote]
How it really works(simplified)
Libtorrent has an 'automanaged' flag for each torrent. This allows libtorrent to start/pause torrents at will depending on the queue limits. If the code pauses an automanaged torrent, libtorrent can unpause it by itself.
So when I/O errors happen libtorrent would pause and periodically unpause to see if the file came back.
However the GUI pause means another thing. It means that we unset the automanaged flag and then we pause the torrent. We do the same when we receive an I/O error. Then libtorrent cannot unpause it by itself.
Also when the session is started and torrents are loaded, even the paused ones get their fastresumes tested. This is why the check fails even for paused torrents.
[quote="Dayman"]
[quote="ciaobaby"]
On BT clients that use the $Partfile.dat convention for unwanted pieces the is only a single 'file' that holds the unwanted pieces.
[/quote]
Suggestions about moving to a single file for unwanted pieces has been out there for a long time, unfortunately I do not think it will be possible to implement w/o overriding libtorrent internals of storage_interface.
[/quote]
And to add to that: I cannot find the exact quote from Arvid(libtorrent author), but when asked about this after he released 1.0.x he said that he considers adding this partfile functionality for the next major version bump for libtorrent. However he mentioned it isn't an easy task to get it right.
Also considering that you'll need at least 1 year for the next major version bump for libtorrent, don't get your hopes up.
[quote="sledgehammer_999"]
How it really works(simplified)
Libtorrent has an 'automanaged' flag for each torrent. This allows libtorrent to start/pause torrents at will depending on the queue limits. If the code pauses an automanaged torrent, libtorrent can unpause it by itself.
So when I/O errors happen libtorrent would pause and periodically unpause to see if the file came back.
However the GUI pause means another thing. It means that we unset the automanaged flag and then we pause the torrent. We do the same when we receive an I/O error. Then libtorrent cannot unpause it by itself.
Also when the session is started and torrents are loaded, even the paused ones get their fastresumes tested. This is why the check fails even for paused torrents.
[/quote]
What about what I experienced, where the files were looked for and where the paused torrents were put in the 0%/must recheck state during runtime?
OK.
Yeah, it did do that. QBittorrent was never closed (until troubleshooting two days later) and the errors occurred for all torrents on the disconnected drive during a single qBT session. I believe they occurred on the same evening the drive was disconnected (I don't know how long after) with all torrents from the drive paused. I did not remove the drive until qBT closed all its file handles.
There were about 150 torrent's files stored on the removed drive, and the errors reported in about a 30-second period were all "File sizes mismatch for torrent X, pausing it."
I was unable to avoid rechecking the torrents.
(If you want more details of exactly what I did, see the second part of the top post in the thread).
[quote="ciaobaby"]
And if the user does not mount by UUID? What you do is not what every body does, qBitTorrent has to cover every unknown combination of anything and everything.
What exactly would you expect to happen if the payload disappears? No BT client can seed from a payload that has simply gone away and what would be the use of downloading pieces that have no way to be placed in the correct location in the payload. You seem to be expecting the client to be almost clairvoyant and anticipate that the drive is about drop out
[/quote]
On Debian system udevil,udisk, udisk2 "disk mounting/automoung" always mount by UUID, the name sde1 sdb1 sdc1 given random. Some torrent applications record the path by UUID which is the best way. Recognition by UUID by client always known the correct path.
I have my torrent files saved to an external usb harddrive. I opened qBittorrent today forgetting to plug it in. On start, the UI froze for a long time. When the UI finally responded again all my files were reported missing (including completed non-seeding files). I plugged drive in and had to do a force recheck on all the files to bring them back.
When I was using uTorrent, it worked better for me. Inactive files are not check. So only seeding files went missing. After the drive is connected again, a simple resume can bring them back, force recheck is rarely needed.
So, I hope no one is discouraged from commenting, even to criticize the proposal constructively, which I welcome as readily as any other relevant thoughts.
