Bug 130507 - Complete files are deleted without confirmation
Summary: Complete files are deleted without confirmation
Status: RESOLVED FIXED
Alias: None
Product: ktorrent
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Joris Guisson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-09 11:01 UTC by Sebastian Trueg
Modified: 2006-11-10 10:40 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Trueg 2006-07-09 11:01:56 UTC
Version:           2.0dev (using KDE 3.5.3, Gentoo)
Compiler:          gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
OS:                Linux (x86_64) release 2.6.16-gentoo-r7

Imagine the following situation:
A torrent has been completed but one file has been deleted by mistake.
To recover that file the torrent is started again but nly for that particular file.
Now KTorrent simply deletes all other files without confirmation because the user only requested the one file.

The correct behaviour should be to ask the user if complete files should be kept or all files should be kept or if everything should be deleted or whatever.
Comment 1 Joris Guisson 2006-07-09 12:44:07 UTC
Euhm we don't do that, the file will be recreated and that's that. I just discovered there is still a bug in the scenario you describe, but that was the symlink not getting removed properly.
Comment 2 Sebastian Trueg 2006-07-09 15:13:10 UTC
What do you mean by "We don't do that"? Deleting files? I honestly do not care 
if the files are deleted or recreated. Isn't it possible to add a check for 
existing files in the same torrent?
Comment 3 Joris Guisson 2006-07-10 09:18:23 UTC
What did you exactly do when you restarted that torrent ?
Comment 4 Sebastian Trueg 2006-07-10 09:46:45 UTC
- The torrent was finished and I removed it from the seeds.
- I then removed some of the downloaded files that I did not need and one that 
I needed by accident.
- I then restarted the torrent by downloading the torrent file and opening it 
in KTorrent the same way as before. Only this time I deselected all but the 
one file I accidentally deleted.
- KTorrent then made the assumption that I don't want the other files (which 
is correct in some way) and deleted (or recreated or whatever but they were 
gone completely, not only empty.) them.

I do not know enough about the torrent protocol and the way KTorrent handles 
the files on disk so I cannot make any assumption about how KTorrent could be 
confused by the fact that I removed some of the downloaded files. But I still 
think a GUI application should NEVER overwrite or delete any files (except 
temp files which were created by the program itself) without confirmation. 
Now one could assume that what I did was kind of a confirmation (deselecting 
all those files). But IMHO that would be a way to technical approach. A GUI 
application should behave as "intelligent" as possible and try to anticipate 
what the user means instead of following some strict logic. In this case: Why 
should a user restart a torrent to delete already downloaded files? It makes 
no sense.
There is only one reason why I would accept this behavior: If KTorrent was 
unable to determine if certain files are complete or not because I deleted 
parts of the torrent.
Comment 5 Joris Guisson 2006-07-10 12:10:38 UTC
1) If you deselect a file from a torrent, the first and last parts of the file are kept around in a temporary file (chunks can lie in multiple files), the rest of that file is deleted.

2) When we open a torrent and there are allready files there, we import those files. When you deselected them they were handled like in 1)

So deselecting the existing files was not necessary (because the import would have found them fully downloaded). We can add a confirmation dialog when preexisting files are deselected, so that this scenario can't happen (well it still can, but then it would be the users' own fault).
Comment 6 Sebastian Trueg 2006-07-10 12:40:53 UTC
On Monday 10 July 2006 12:10, Joris Guisson wrote:
> would have found them fully downloaded). We can add a confirmation dialog
> when preexisting files are deselected, so that this scenario can't happen
> (well it still can, but then it would be the users' own fault).


yes, please do that. I know that it was not necessary but I was tired and 
that's when stuff like that heppens. ;)
Comment 7 Joris Guisson 2006-07-10 13:11:11 UTC
SVN commit 560445 by guisson:

Changes :
- Added confirmation dialog when deselecting preexisting files (130507)
- Only delete empty directories when a torrent and it's data are removed

BUG: 130507



 M  +32 -0     apps/ktorrent/fileselectdlg.cpp  
 M  +9 -12     apps/ktorrent/ktorrentcore.cpp  
 M  +1 -0      apps/ktorrent/main.cpp  
 M  +3 -1      libktorrent/interfaces/torrentfileinterface.cpp  
 M  +7 -1      libktorrent/interfaces/torrentfileinterface.h  
 M  +5 -1      libktorrent/interfaces/torrentinterface.h  
 M  +6 -0      libktorrent/torrent/cache.h  
 M  +5 -0      libktorrent/torrent/chunkmanager.cpp  
 M  +2 -0      libktorrent/torrent/chunkmanager.h  
 M  +71 -3     libktorrent/torrent/multifilecache.cpp  
 M  +2 -1      libktorrent/torrent/multifilecache.h  
 M  +4 -0      libktorrent/torrent/singlefilecache.cpp  
 M  +1 -0      libktorrent/torrent/singlefilecache.h  
 M  +5 -0      libktorrent/torrent/torrentcontrol.cpp  
 M  +1 -0      libktorrent/torrent/torrentcontrol.h  
Comment 8 Colin Snover 2006-11-10 09:19:55 UTC
I am running KTorrent 2.0.3 using KDE 3.5.2 (Kubuntu 6.06 using the backports repository) and continue to experience this behaviour. I accidentally deselected a completed file from a multi-part torrent, and when I did that, all chunks except for the first and last chunk were deleted from that file with no confirmation or prompting from KTorrent. If it makes any possible difference in this context, I'm saving files to a mounted NFS share.
Comment 9 Joris Guisson 2006-11-10 10:40:30 UTC
This is not part of 2.0.3