Opened 13 years ago

Closed 12 years ago

Last modified 11 years ago

#1302 closed Bug (fixed)

Transmission doesn't notice when users delete downloaded files manually

Reported by: smmalis Owned by: charles
Priority: Normal Milestone: 1.40
Component: libtransmission Version: 1.34+
Severity: Normal Keywords:
Cc:

Description

If a file is deleted that Transmission is uploading, the message log reports "generic i/o errno from errno: No such file or directory". Upon receiving this message, Transmission should automatically run a "Verify local data", because something obviously went wrong.

Attachments (1)

log.txt (5.9 KB) - added by smmalis 13 years ago.
gdb log

Download all attachments as: .zip

Change History (33)

comment:1 Changed 13 years ago by smmalis

now that generic i/o errno has been eliminated, nothing shows up in the message log.

comment:2 Changed 13 years ago by charles

smmalis: what is the use case for this? did you delete a file from a torrent that you were still seeding?

comment:3 Changed 13 years ago by smmalis

That's exactly it. Not sure if this applies to any file you're uploading or only when seeding, but that's when I've seen it.

comment:4 Changed 13 years ago by charles

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

Why on earth would you delete a file in a torrent that you're still seeding?

comment:5 Changed 13 years ago by smmalis

  • Resolution invalid deleted
  • Status changed from closed to reopened

It could be an accident, and you don't even realize it. If that's the case, the file wouldn't redownload or anything.

comment:6 Changed 13 years ago by charles

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

comment:7 Changed 13 years ago by smmalis

  • Resolution invalid deleted
  • Status changed from closed to reopened

The cases where it happens may be few, but think about it. The bottom line is that if something causes an error while Transmission happens to be uploading a file, Transmission should automatically run a Verify Local Data.

comment:8 Changed 13 years ago by Gimp

Its not up to transmission to automatically verify the file if there is an error. What if its on an external hard drive and you just unplugged it? you don't want it to verify, then you have to verify again when you plug it back in.

Besides, verifying then, would make the torrent start at 0 and begin downloading. This ticket is invalid.

Transmission should report a simple "File not found" to the end user, and PERHAPS pause the torrent. but thats all.

comment:9 Changed 13 years ago by charles

smmalis: could you give r6880 try and see what the results are?

comment:10 Changed 13 years ago by smmalis

I'm downloading a torrent now. When it finishes, I'll delete the file and see what happens.

comment:11 Changed 13 years ago by smmalis

Transmission crashed as soon as I deleted the file.

comment:12 Changed 13 years ago by smmalis

Running in a terminal gives:

transmission: ptrarray.c:102: tr_ptrArrayNth: Assertion `i < t->n_items' failed.
Aborted

comment:13 Changed 13 years ago by smmalis

Gimp makes some valid points, and I agree with his proposed solution. It seems now when the file disappears while seeding that Transmission crashes (see above), but on restart the torrent is paused.

comment:14 Changed 13 years ago by charles

smmalis: could you attach a valgrind or gdb trace of the crash?

comment:15 Changed 13 years ago by smmalis

I will as soon as this torrent finishes.

comment:16 Changed 13 years ago by smmalis

Here you go. I was receiving a lot of SIGPIPEs at first, so I told GDB to handle them.

Changed 13 years ago by smmalis

gdb log

comment:17 Changed 13 years ago by charles

smmalis: I apprecate the log, but it appears to have been made from an executable with the debugging information stripped out, like you'd see from a "make install".

Could you rebuild the libtransmission/ and gtk/ directories for better debugging (change the -O and -g arguments in CFLAGS to -O0 -ggdb3 in their respective Makefiles, then "make" again) and attach a gdb log from the executable that's created in the gtk/ directory?

I tried this myself by deleting from disk a torrent that Transmission was seeding. Unfortunately(?) for me Transmission did the Right Thing and just stopped the torrent instead of crashing...

comment:18 Changed 13 years ago by charles

For example, this is from the previous log:

118 	No symbol table info available.
119 	#4  0x0808c75d in tr_ptrArrayNth ()
120 	No symbol table info available.
121 	#5  0x080a8d85 in ?? ()
122 	No symbol table info available.
123 	#6  0x08097d18 in ?? ()
124 	No symbol table info available.

We can see that tr_ptrArrayNth() is in the call stack at level #4, but because #5 is empty we don't know who called it before it crashed... basically all we know is that someone somewhere in the program called tr_ptrArrayNth() right before the crash. That function is called 11 places in libtransmission, so getting that function name in #5 will eliminate over 90% of the suspects... :)

comment:19 Changed 13 years ago by smmalis

Torrent is downloading now with a debugging version of libT and gtk. Is it possible (or a good idea) to put those flags in automatically? I don't know much about makefiles, but could it be changed so automake does that for everyone building from svn? Seems like it would be helpful for bug reports.

comment:20 Changed 13 years ago by smmalis

#4  0x08086903 in tr_ptrArrayNth ()
No symbol table info available.
#5  0x0809f5e6 in ?? ()
No symbol table info available.

Doesn't seem to have worked.

comment:21 Changed 13 years ago by charles

Could you walk me through the exact steps you're doing to trigger this bug?

comment:22 Changed 13 years ago by smmalis

Start up Transmission (current state doesn't matter). Add a torrent or use one already downloaded (it doesn't matter). Seed the torrent. Wait until actually uploading something. Delete/Move/Eject? file from the torrent. Crash.

Maybe this only happens with single file torrents? Or if you move everything the torrent downloaded (not just one file)?

comment:23 Changed 13 years ago by charles

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 1.40
  • Owner set to charles
  • Status changed from reopened to new
  • Version changed from 1.34 to 1.34+

forum user jh has come to the rescue:

0   libSystem.B.dylib                0x93392fa4 __semwait_signal_nocancel + 8
1   libSystem.B.dylib                0x93392a70 nanosleep$NOCANCEL$UNIX2003 + 176
2   libSystem.B.dylib                0x93383c08 usleep$NOCANCEL$UNIX2003 + 68
3   libSystem.B.dylib                0x933a92bc abort + 92
4   org.m0k.transmission             0x0007615c __eprintf + 76
5   org.m0k.transmission             0x000577c4 tr_ptrArrayNth + 100
6   org.m0k.transmission             0x0005dde8 pumpAllPeers + 88
7   org.m0k.transmission             0x0005ea9c bandwidthPulse + 672
8   org.m0k.transmission             0x00058124 timerCallback + 40
9   org.m0k.transmission             0x00071474 event_base_loop + 1332
10  org.m0k.transmission             0x00058318 libeventThreadFunc + 140
11  libSystem.B.dylib                0x932c4658 _pthread_start + 316

comment:24 Changed 13 years ago by charles

possible fix in r6940.

comment:25 Changed 13 years ago by smmalis

IT WORKS!!! YAY!!! Now then, part 2: Upon hitting Resume, if the torrent was paused for that reason, it should Verify.

comment:26 Changed 12 years ago by charles

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

about "part 2", I'm more in agreement with Gimp in comment 8.

comment:27 Changed 12 years ago by smmalis

  • Resolution fixed deleted
  • Status changed from closed to reopened

I am too, but the problem now is that after this pause occurs, if the user hits Resume without verifying, the old behavior returns.

comment:28 Changed 12 years ago by charles

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

If a red torrent saying "no such file or directory" isn't enough of a clue to the general user then nothing that we do is ever going to be enough.

comment:29 Changed 12 years ago by smmalis

  • Resolution fixed deleted
  • Status changed from closed to reopened

The problem is though, that the old behavior still exists. Here's an idea: Don't let the torrent resume until it has been verified after this error?

comment:30 Changed 12 years ago by charles

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

smmalis: If you reopen this ticket for a fifth time I will delete your account.

comment:31 Changed 12 years ago by charles

  • Summary changed from Uploading file deletion is ignored to Transmission doesn't notice when users delete downloaded files manually

comment:32 Changed 11 years ago by sim

(deleted spam)

Last edited 11 years ago by charles (previous) (diff)
Note: See TracTickets for help on using tickets.