About disk allocating.. can you make option from which you can enable or disable it?
reason for this request : on low pc this take a lot of time and make the system temporary unstable and this can't work normally with fat32 fs.. (i'm using current svn)

DeViL wrote:About disk allocating.. can you make option from which you can enable or disable it?
reason for this request : on low pc this take a lot of time and make the system temporary unstable and this can't work normally with fat32 fs.. (i'm using current svn)

It doesn't take any time at all on reiserfs, are you sure you have the latest ? I haven't tested the feature on fat filesystems.

George wrote:It doesn't take any time at all on reiserfs

Same for ext3.

Oh right on ext3 it doesnt take any time but on fat it take a lot time and with current svn it can't allocate disk space if you don't restart the program after torrent's start.

I guess that's a ftruncate issue then? Hmm, if it is then the question comes "do you want KTorrent to support fat32?"

I personally don't see an advantage of fat32: it's old, has high fragmentation, doesn't support files larger than 4GB and has no right management.
I think due to the 4GB filelimit it's more important to get it to work on NTFS in the future. (for the sake of potentially porting it to windows after KDE 4)

But on the other hand some people use a fat32 partition to get the files accesible on both windows and linux. (or perhaps they could use something like ext2fs.(?))

Stoeptegel has hit the nail right on the head :

On the one hand people use it to share files between windows and linux, so we should support it. But on the other hand it is old, has many limitations, which forces us to work around these things, which is annoying and quite frankly a ****.

EDIT: some googling turned up a small workaround for fat32, didn't test it with big files yet, but it should work.

I just want to say that I lost several hours of download of a multifile torrent due to FAT problems (which I am using as storage for _all_ my data on the dual-boot system)...

I perfectly understand that ktorrent cannot support this FAT32-crap, but it should be more robust in handling errors, allowing me to preserve the state of downloaded stuff when an error occurs instead of ereasing all data (a third button after clicking on a torrent saying "safe torrent file and then start downloading would help here - since ktorrent removes the torrent data from its temporary directories when things go wrong!).

Furthermore, as opposed to what was written in the FAT-related threads, the temporay directories under .kde/share/apps/ktorrent may become significantly large, if one deletes partially downloaded files from a multifile torrent. One should be aware of that! (In my case this filled my 10GB reiser partition casuing the system to get clogged; while copying the deleted files from FAT took an eternity and seemingly froze the system). (I am using the 2.0beta1)

Turtoise72 wrote:I just want to say that I lost several hours of download of a multifile torrent due to FAT problems (which I am using as storage for _all_ my data on the dual-boot system)...

I perfectly understand that ktorrent cannot support this FAT32-crap, but it should be more robust in handling errors, allowing me to preserve the state of downloaded stuff when an error occurs instead of ereasing all data (a third button after clicking on a torrent saying "safe torrent file and then start downloading would help here - since ktorrent removes the torrent data from its temporary directories when things go wrong!).

We will get rid of the delete, and rename the torX directory to something like failed-torX.

Furthermore, as opposed to what was written in the FAT-related threads, the temporay directories under .kde/share/apps/ktorrent may become significantly large, if one deletes partially downloaded files from a multifile torrent. One should be aware of that! (In my case this filled my 10GB reiser partition casuing the system to get clogged; while copying the deleted files from FAT took an eternity and seemingly froze the system). (I am using the 2.0beta1)

This has been solved in current SVN. But if you deselect now, you will lose most of the data of those files.

George wrote:This has been solved in current SVN. But if you deselect now, you will lose most of the data of those files.

I see that it works now as I had asked for: Stupid me wanted to set a file within a multifile torrent from "Yes" to "Yes, Last" and accidentally hit "No" - and all the chunks of that file were lost in an instant.

Hmm, maybe it's ok that way, maybe a seperator between "Dowload last" and "Not at all" is enough. A "yes, really"-dialogue is probably too annoying. I would actually prefer if Ktorrent would wait a few seconds (or an "Apply" button), but that probably not to easy to implement...

Thanks for Ktorrent btw! It really is great (despite myself nitpicking here)!

I suggest switching your shared drive to ext3, and using the [url http://www.fs-driver.org/]Ext2/3 IFS[/url] driver for windows (2k, XP, Vista).

Then you can see your nice ext2/3 drive in both linux and windows.