Opened 12 years ago

Closed 12 years ago

#3379 closed Bug (duplicate)

upon startup, transmission decided to verify a bunch of files w/o permission;

Reported by: Astara Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.01
Severity: Normal Keywords:
Cc:

Description

For some reason, for the past hour since I restarted the daemon client, transmission took about 30 or more torrents and decided it wanted to verify them -- even though they are at 100% and should be seeding.

Has some change gone in that would cause this unwanted behavior?

How do I kick them out of the 'waiting' phase? For some reason it is ignoring me when I tell it to start.

Perhaps 'start' should override 'wait' and start with whatever the file has (which in most cases is 100%).

(see attached).

Attachments (1)

transmission.png (118.4 KB) - added by Astara 12 years ago.
picture of transmission's self-selection of files to verify

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by Astara

picture of transmission's self-selection of files to verify

comment:1 Changed 12 years ago by Rolcol

Transmission verifies the files if it appears that they were changed. It does this so it doesn't send bad data to other peers. I think this ticket will be closed by the devs as being superseded with #2955.

comment:2 Changed 12 years ago by charles

  • Resolution set to duplicate
  • Status changed from new to closed

Closing this as a duplicate of #2955.

Though, since you also are complaining of zombie .torrent files, I wonder if there's not a write permissions issue in your config directory.

comment:3 Changed 12 years ago by Astara

  • Resolution duplicate deleted
  • Status changed from closed to reopened

This isn't a request for an enhancement -- someone implemented code that broke something that was working. That's called a regression. Those are considered severe bugs -- because they took something that was working and broke it.

I *said* that they couldn't rely on modification times as to whether the content had changed. IT is unreliable. I can change content without changing modification times and I can change modification times without changing content.

If the *size* changes, then it's different -- but if its 100% complete now, and 100% complete later -- it shouldn't be presumed to have change.

It is clear that transmission is verifying files when I didn't ask it to. That's a bug. The files are not different. It just up and started verifying them because someone 'thought' they were different? They are my files. If I want to verify them, I will. I *would* like the idea of periodic background verifications, but this isn't background and it isn't voluntary -- I didn't ask for them to be verified -- i.e. unwanted behavior -- that used to not happen.

Something was broken.

comment:4 Changed 12 years ago by charles

Files are preallocated to avoid fragmentation, so judging by file size is even less reliable.

If you have a suggestion for detecting changes that doesn't rely on mtimes or file sizes, I'd like to hear them.

comment:5 follow-up: Changed 12 years ago by tiennou

Sorry, just my 2 cents, but I'm pretty sure I've saw it happen already (starting from around 2.00, but I'm on the nightlies). There had been times when I did a simple Stop All / Start All cycle (not even quitting T) and it diligently reverified all the files that were active when I stopped so either it is going nuts with verification, or there was something that modified my files behind my back…

@charles: Use some kind of checksumming, like md5 or SHA or whatever is not too CPU-intensive. It will work around the unreliability of mtimes.

comment:6 in reply to: ↑ 5 Changed 12 years ago by charles

Replying to tiennou:

@charles: Use some kind of checksumming, like md5 or SHA or whatever is not too CPU-intensive. It will work around the unreliability of mtimes.

!!!

comment:7 Changed 12 years ago by charles

  • Resolution set to duplicate
  • Status changed from reopened to closed

Okay. First, the big picture: I marked this as a duplicate of the "lazy verify" ticket because that would eliminate verify-on-startup and therefore eliminate this code, regardless of whether the current ticket's problem is caused by a regression, a pre-existing bug, or a pre-existing feature. As such, I'm re-closing this ticket.

That said, there are a few things in comment #3 that need to be addressed because I'd like our tickets to be more productive:

This isn't a request for an enhancement -- someone implemented code that broke something that was working. That's called a regression. Those are considered severe bugs -- because they took something that was working and broke it.

I *said* that they couldn't rely on modification times as to whether the content had changed. IT is unreliable. I can change content without changing modification times and I can change modification times without changing content.

If the *size* changes, then it's different -- but if its 100% complete now, and 100% complete later -- it shouldn't be presumed to have change.

It is clear that transmission is verifying files when I didn't ask it to. That's a bug. The files are not different. It just up and started verifying them because someone 'thought' they were different? They are my files. If I want to verify them, I will. I *would* like the idea of periodic background verifications, but this isn't background and it isn't voluntary -- I didn't ask for them to be verified -- i.e. unwanted behavior -- that used to not happen.

Something was broken.

  • It's condescending to lecture me on the definition of a regression. The message I see in that paragraph is that you don't see this as a conversation between two adults. Perhaps it's not clear when reading that paragraph in isolation, but it's an implication I've seen repeatedly in our previous discussions. If that implication wasn't intentional, please choose your words more productively. If that implication was intentional, then go pick arguments with someone else.
  • When you write "I *said*" and "IT is unreliable", the emphasis on "said" and "it" scans as if you're trying to argue or are being defensive. Please use a neutral voice.
  • I don't understand what you're referring to by the phrase "I *said*". I don't see the previous discussion that you're referring to.
  • Testing by file size is a very good suggestion. Unfortunately it's not workable in Transmission because files are preallocated to avoid disk fragmentation. (Whoever says Unix filesystems don't fragment, doesn't use p2p ;)
  • You assert that unrequested verification of files is a bug. This is a matter of opinion. The counterpoint is that BitTorrent? clients have a responsibility to verify a file's correctness if it thinks something has changed. Sharing corrupt data would result in the BitTorrent? client being (rightly) banned.
  • You assert (four times) that this is a new bug. While doing so, you again use a hostile tone and again lecture. In truth, the code that decides when to verify hasn't changed significantly in a long time. A stronger possibility is that the change is something in your configuration. Some common triggers are: (1) file permission errors in your config directory, (2) file mtimes somehow being changed by the OS, (3) the .resume file was not successfully saved to disk the last time Transmission was shut down, either due to a crash or abrupt system shutdown. There are other causes, but those are the most common.

tl;dr: use a neutral tone. use less repetition. don't pick arguments. don't lecture the obvious. don't make assertions without solid evidence. thank you.

Note: See TracTickets for help on using tickets.