Opened 12 years ago

Closed 12 years ago

#2183 closed Bug (fixed)

.torrent files created with odd file permissions

Reported by: m1b Owned by: charles
Priority: Normal Milestone: 1.71
Component: libtransmission Version: 1.70
Severity: Normal Keywords:
Cc:

Description

Somewhere between r8469 (last known-good nightly) and r8478 a change was introduced that causes specific torrent files to be forgotten across relaunches. (r8473 is a very inconvenient build for torrent lists, since it reproducibly removes all listed files.)

Steps to repro are:

  • Add the .torrent to the list
  • T will appropriately verify local content and then start seeding; there is nothing apparently wrong with the .torrent
  • Quit and relaunch (eg after using sparkle to update to the latest nightly)
  • That specific .torrent will not be in the list after T comes up again

This does not happen with all .torrents; thus far I only have this single example, but it reproduces reliably. (The repro system is Leopard PPC.)

Looking at the .torrent with btshowmetainfo (from the mainline 4.x distribution) or with btinfo (from the btpd 0.15 release) yields no useful info; the torrent appears fine.

This problem reproduces with all builds from r8478 onward, including the current nightly r8654.

Change History (14)

comment:1 Changed 12 years ago by m1b

Two more things:

  • When re-adding the torrent after a relaunch, T will find the locally cached hash info and not re-verify the local content
  • Also, when adding the torrent, there is no complaint from T (neither T's log in debug mode, nor console.app) about the .torrent, which makes sense given the non-complaint from btshowmetainfo and btinfo.

comment:2 Changed 12 years ago by livings124

I can't replicate this. I add the torrent in 1.71, quit, relaunch, and it's still there. Am I missing something in the procedure?

comment:3 Changed 12 years ago by charles

m1b: thanks very much for going through the versions to see where it starts happening for you. I can't reproduce this either, but I know what a pain it is to cycle through old versions like this, so, hat tip to you.

Going from this statement: "Somewhere between r8469 (last known-good nightly) and r8478 a change was introduced that causes specific torrent files to be forgotten across relaunches.", here are our candidates:

r8478 charles (trunk) dht seems to be crashing in bcmp() on the mac, so I suspect the …

r8477 charles (1.6x libT) backport r8465, which defers building the …

r8476 livings124 (1.5x) update NEWS

r8475 livings124 (1.6x) update NEWS

r8474 livings124 (1.6x) cleanup last commit(s)

r8473 livings124 cleanup last commit(s)

r8472 livings124 (1.6x) backport r8470-r8471

r8471 livings124 remove a little redundant code from the last commit

r8470 livings124 save internal torrent path to history, and prefer that over the hash when …

r8469 charles (trunk libT) take out the test scaffolding for the tr_torrentFiles() …

comment:4 Changed 12 years ago by charles

r8469, r8475, r8476, and r8478 are not the problem.

comment:5 Changed 12 years ago by livings124

You're not saying it's lost when switching from one of those versions to another are you? That's not a concern, the concern is only with released versions.

comment:6 Changed 12 years ago by charles

m1b: could you mail us one of the .torrent files you're seeing this behavior in?

comment:7 Changed 12 years ago by charles

m1b: also, does r8660 improve things any? (background: #2192)

comment:8 Changed 12 years ago by charles

m1b: ping

comment:9 Changed 12 years ago by m1b

Heavy sigh -- I was getting no notifications about updates to this ticket. Sorry for the perceived absence.

r8667 still exhibits the behavior, ie when I update to the latest nightly and have n torrents active, upon relaunch there will be n-1 and the one in question is the missing one.

A clarification to the above: r8469 is definitely not the problem; the .torrent survives quit and relaunch. This is the last build that behaves correctly.

charles: I sent you and livings the specific torrent that exhibits the problem.

comment:10 Changed 12 years ago by charles

  • Component changed from Transmission to Mac Client
  • Owner set to livings124

comment:11 Changed 12 years ago by livings124

Can you delete your preferences and library files and see if this continues?

comment:12 Changed 12 years ago by m1b

I followed livings124's suggestion and removed prefs, ~/Library/AppSupt/Transmission/? and ~/Library/Caches/Transmission/?.

After some trial and error, I discovered that the .torrent in ~/Library/AppSupt/Transmission/Torrents/? that corresponded to the misbehaving one had 100 permissions rather than 644. I have no clue how this happened.

Good news: Setting that file's perms to 644 makes the problem go away.

Even if we write this off as a freak occurrence, this is not the most graceful of failures; is there a reasonable way to improve the catching and reporting of this kind of error?

comment:13 Changed 12 years ago by livings124

  • Component changed from Mac Client to libtransmission
  • Owner changed from livings124 to charles

comment:14 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.71
  • Resolution set to fixed
  • Status changed from new to closed
  • Summary changed from .torrent file forgotten across relaunches to .torrent files created with odd file permissions

This permissions problem is already fixed in trunk (and 1.71) in r8611

Note: See TracTickets for help on using tickets.