There I was, all alone - in debugging hell.

Why was our GUI not able to display the required disk space that was needed? Why was it showing 0?!

And why did our unit tests of the FileManager all shine of vibrant green?!

I started deep in the mounts of what our prophets label the business layer -- it was correctly calculating the bytes based on the file sizes.

I continued upward towards the swamp-like territory of the GUI-people.

There I stood. Face to face, with...

int gb = (int)fileManager.RequiredDiskSpace / 1024 / 1024 / 1024;

I'm not sure what's worse here. The fact that "gb" can only take two different values (zero or one) on 32-bit systems, or the lack of rounding causing huge accuracy problems (0.99GB anyone?)

Probably should make those floats or doubles anyway. That way you can't screw up! (but you still will)

Sadly reminiscent of a certain company's installers which - last time I checked - still hadn't been updated for that magical moment when drives > 2gb became not only possible, but also commonplace. Shudder.

To be politically correct, that should say:

int GiB = (int)fileManager.RequiredDiskSpace / 1024 / 1024 / 1024;
 

I should never have digged through this part of the code base.

In a function (EstimateTime), a background thread with a while(true) loop (terminated using Abort() -- yeah, Abort), at the end I found this comment:

Thread.Sleep(500); // Estimate time every 5 seconds.

Yeah, that's not how milliseconds work.

And why not use the built in C# class Timer?

I don't know. I give up.

Granted this question is dependent on when that code was written, but int is normally 2^(number of bits in the CPU). So on a modern processor (64 bit) an unsigned int or even int shouldn't be a problem.

Though to be clear, I know a long would be the better and safer choice.

Actually, int remains 32-bits for most languages and compilers out there.

Really? I thought it was based on the CPU and you had to target the compiler to 32-bit or whatever XX-bit.