#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)
Change History (33)
comment:1 Changed 12 years ago by smmalis
comment:2 Changed 12 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 12 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 12 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 12 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 12 years ago by charles
- Resolution set to invalid
- Status changed from reopened to closed
comment:7 Changed 12 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 12 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 12 years ago by charles
smmalis: could you give r6880 try and see what the results are?
comment:10 Changed 12 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 12 years ago by smmalis
Transmission crashed as soon as I deleted the file.
comment:12 Changed 12 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 12 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 12 years ago by charles
smmalis: could you attach a valgrind or gdb trace of the crash?
comment:15 Changed 12 years ago by smmalis
I will as soon as this torrent finishes.
comment:16 Changed 12 years ago by smmalis
Here you go. I was receiving a lot of SIGPIPEs at first, so I told GDB to handle them.
comment:17 Changed 12 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 12 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 12 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 12 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 12 years ago by charles
Could you walk me through the exact steps you're doing to trigger this bug?
comment:22 Changed 12 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 12 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 12 years ago by charles
possible fix in r6940.
comment:25 Changed 12 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)
now that generic i/o errno has been eliminated, nothing shows up in the message log.