Ticket #3586 (new defect)

Opened 12 months ago

Last modified 3 months ago

File transfers are never canceled for real

Reported by: Edtech Owned by: asterix
Priority: high Milestone: 0.13
Component: usability Version: svn
Severity: critical Keywords:
Cc: OS: All

Description

If you cancel a transfert, the file is not released and do not can be removed as long as Gajim was not closed.

Attachments

Change History

Changed 12 months ago by steve-e

  • version changed from 0.11.3 to 0.11.4
  • milestone changed from 0.11.4 to 0.12

Changed 5 months ago by js

  • owner changed from asterix to js

Changed 3 months ago by js

  • owner changed from js to asterix
  • priority changed from normal to high
  • version changed from 0.11.4 to svn
  • os changed from Windows to All
  • summary changed from Cancel a transfer blocks the deletion of the downloaded file to File transfers are never canceled for real

I had a look at this, Asterix. It's not a Windows bug, it's a deeper bug - Windows just showed it because it can't delete opened files.

Gajim never closes the file handle when you cancel a transfer. In fact, it doesn't even cancel it properly. That explains why someone sometimes got a file that I already canceled. Everything that Gajim does it remove it from the FT window and send a rejection stanza, nothing more.

If you cancel the file before the other side accepts, the other side is still able to get the whole file. What we do is: We send a rejection and rely on the other side to close the stream. But that never closes our file handle. And if the other side doesn't close, we still transfer.

We need to rewrite cancelling file transfers, as this doesn't work at all.

I had a look at it, but I think the whole file transfer code is a bit strange - GUI and actual file transfer code is happily mixed. Could you maybe fix this, Asterix? You can also see on Linux that the file (and the stream, if the other side doesn't close it!) is never ended using lsof.

Changed 3 months ago by asterix

  • milestone changed from 0.12 to 0.13

Changed 3 months ago by js

  • severity changed from normal to critical
  • milestone changed from 0.13 to 0.12

Asterix, this is for 0.12 IMO, as this is a serious bug. It may leak private information, for example if you drop a file by accident in the chat window. Now you cancel it, but the other side still receives it - VERY, VERY bad. Already happened to me.

Changed 3 months ago by asterix

  • milestone changed from 0.12 to 0.13

this is in Gajim since ages, and nat many ppl complains. Ok it's bad, but it's hard to fix, and I don't want to release in 2 monthes. As currently all dev seems to be busy, I won't fix that for 0.12.

Add/Change #3586 (File transfers are never canceled for real)

Author



Change Properties
<Author field>
Action
as new
as The resolution will be set. Next status will be 'closed'
to The owner will change. Next status will be 'new'
The owner will change to anonymous. Next status will be 'assigned'
 
Note: See TracTickets for help on using tickets.