Forums Feature Suggestions Reserve Disk Space For DCC Transfers

I problem I have noticed with mIRC if you are download a few files at once is that they become veyr fragments. I know this is mainly a problem with the windows filesystems but one way that download managers have tried to fix this issue to to prefill the file first therefore reserving the diskspace in one go thus reducing the fragments the file should have.
I think it could be good to have an option to do this.

While I don't see a problem with that, others might argue that mIRC isn't a file sharing application and as a result shouldn't need to goto those lengths just to keep the windows filing system happy.

Eamonn.

I guess I'm with the "others" then; additionally, wouldn't this feature make DCC resuming pretty much impossible in case of unexpected program termination at the receiver side (ie. in the case that mIRC doesn't have the opportunity to size back the file first)?

That is a very good point, its not really a major thing but would be handy!
I guess its just a case of regularly defragmenting!

I doubt even alocating all the space of the file at once well defragment the drive that much, but if your really concerned, you could copy the file on completion to another location, then delete the original, that in some ways well reduce the possable fragmenting of it.

While you bring up a valid point it wouldn't exactly be hard to resume, for example at the moment mIRC grabs the filename checks if it exists, if so and the recieving file is bigger than the stored one, checks if its 'so-far' the same, and removes a few bytes then resumes from there..

Resuming with preallocated space would be, i.e. the file:

DATADATADATADATA0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

It would simply find the last relivant data item, 'A' and remove a few bytes and start from there.. so it wouldn't be really hard.

As for whether it would reduce fragmentation, I don't have a clue.

Eamonn.

Searching for the last byte of data might be a bit time consuming, there is of course the division by two method that somone could say well produce only 12 reads to find it (to the 1kb), but then if the file has chuncks of null bytes in it, your going to run into false end of datas.

If I had to think of something I would uses a system of a length downloaded, stored at the end of the file (same as kazza uses minus all the chunks downloaded data), this caan get update as the file is written to and/or every 1meg (i say who cares if u have to redownload a meg), when the file completes its earsed off the end (might be an idea to have a idenifying ID with it, so mirc can see its one of its headers and deal with the file accordingly.

Personally I think the whole idea is full of problems and would run into more as it went on, especially with older mircs storing recieved files one way and the newer ones storing them another, an incomplete file starts gettng sent around beleived to be a complete one sicne it appears to be the right length etc etc.

Oh and the one real concern i would have is just how easy it would be to lag someone off irc with a mirc doing this.