Pre-allocate disk space option off has no effect

Is it me or does the 'pre-allocate disk space' option not work? That is, it seems to always pre-allocate the space!

I was expecting that, with this setting off, it would incrementally download the file? Like BitTornado does… If not, what is the point in having the setting?

It surely explains why I'm suddenly running out of disk space…

~Grauw

Okay, that's not the same thing, but:

µTorrent always allocates the entire file regardless of how much data was downloaded from it.

That's what I feared…

There is no need to allocate the entire file at once, you can download to the start of the file, and move the piece to its correct position once the file is large enough, e.g.:

Download file, size 4 blocks (numbers 1, 2, 3 and 4):

[]

Download piece 4:

[4]

Download piece 2:

[4 2]

Download piece 1:

[x 2 4]

[1 2 4]

Download piece 3:

[1 2 x 4]

[1 2 3 4]

That way you can download incrementally…

Advantages: saves space, given that I have 4 GB of disk space, I can download one slow 4 GB torrent, and download loads of small ones at the same time, as long as I make sure they are burned to a DVD or moved to another disk once the 4 GB file is finished.

Disadvantages: It fragments when downloading multiple torrents at once, and extra read/write actions are necessary so there is more disk access. Best case: no extra read/write actions. Worst case: 1 extra read/write for each block.

In pseudo-code:

class BTFile {
    int length
    int[final.length] wrong        // initialised to -1's

    void store(Block block) {
        pos = length            // set initial store position

        // if block for the current position is elsewhere,
        // then move it to correct position
        //
        if (wrong[length] != -1) {
            pos = wrong[length]
            move(wrong[length],length)
        }

        // if block position is occupied by other block,
        // then move other block away
        //
        if (block.no < length && pos != block.no)
            move(block.no,pos)
            pos = block.no
        }

        // write block to store position
        //
        write(pos,block)
    }

    void move(int from, int to) {
        write(to,read(from))
    }

    void write(int pos, Block block) {
        if (pos != block.no)            // update wrong table
            wrong[block.no] = pos        // written to wrong position
        else
            wrong[block.no] = -1        // written to correct position
        ...
    }

    block read(int pos) {
        ...
    }
}

And of course there is the additional complication because files don't always start immediately at index=0. Then you need to special case for writes overlapping multiple files. But that can be solved transparently in write().

I would imagine that the 'Pre-allocate disk space' option controls whether it uses this method (off) or pre-allocates the files (on).

Hope this is useful, and you will implement the feature .

~Grauw

Unlikely.

Why not?

Amongst others BitTornado and I think Azureus do it as well, and it is quite convenient.

It certainly makes sense as an option for those with harddrives that are always full (like mine). It does have its disadvantages, but it also has advantages (gives time to move / burn data to make room before allocation) that may be desirable to some.

Sad to hear it is unlikely. This client is really shaping up, and though this isn't an issue for me at this moment, I can forsee it being one...

This has now been implemented in 1.6.1 by means of the "sparse files" in the advanced options.

And I really like the NTFS-implementation you used, the file still shows up as its final size (which confused me a bit initially), but when you view its properties then the size on disk is the downloaded size!

~Grauw