please help me, help my friend with some homework, that i thought was mad easy, but i'm stumped!!!

[spanky]

the question goes like this:

using any method on your updated windows 2000/xp system, record the following for C:
size of all files ________
size of al files on disk ________

first of all... what is the difference between those two? they sound the same to me
secondly... how do i find out the size of all files on my C: in windows xp? i know in windows 98, i can just look at the porperties of my C:, but it appears that is not the case with xp. anyone?

 

[stevens]

I run XPpro and all i do is look at propeties and it gives me that pie graph of the used space on my drive.

 

[Frosty3799]

you can right click and hit properties on the c drive to find size of all files on disk

EDIT: when i go into my c:/ dir and select all, and then click properties, i get:

Size: 3.49 GB (3,748,083,370 bytes)

Size on disk: 3.38 GB (3,638,677,616 bytes)

i htink windows xp compresses stuff you dont use

 

[spanky]

thanx guys.

but anyone wanna take a stab at the difference between "size of all files" and "size of all files on disk"?

 

[MajesticMoose]

I think, and i could be very wrong, that the size of all files is how much room they really need based on the amount of info in the files. THe size of all files on disk is the amount of space they take up due to the way a HDD worksstores data.... cluster size something or other.... blah blah...

 

[spanky]

Originally posted by: MajesticMoose
I think, and i could be very wrong, that the size of all files is how much room they really need based on the amount of info in the files. THe size of all files on disk is the amount of space they take up due to the way a HDD worksstores data.... cluster size something or other.... blah blah...

hmm... that sounds logical so would u happen to know where i can find this info under windows xp?

 

[Alphathree33]

I could also be very wrong, but I believe that regardless of the size of any given file, it will always take up at least one cluster. (For example 32 kB)

So if you had a billion 1 kB files, they would still take up 32 billion kB on disk (errrr, right that would be 32 terabytes I think... )

EDIT: I think if you can find somewhere where you can mess with FAT32/NTFS settings, you should be able to find out the cluster size for a given disk.

 

[JW310]

MM is pretty close... if your system uses 4KB clusters, any file that's less than 4KB will take up exactly 4KB on the disk. So a 1 byte file will take up 4 KB on disk. Two 1 byte files will take up 8KB on disk, and so on.

As for finding this info, open up the C: drive, set it to show all files, Ctrl-A to select all files, and then Alt-Enter to see the properties. It should show the size of all files, and the size of all files on disk.

JW

 

[SWirth86]

If you click properties on a specific file in XP, it tells you the 'size' and 'size on disk'. Not sure on how to get it for everything though.....

 

[MajesticMoose]

Originally posted by: Alphathree33
I could also be very wrong, but I believe that regardless of the size of any given file, it will always take up at least one cluster. (For example 32 kB)

So if you had a billion 1 kB files, they would still take up 32 billion kB on disk (errrr, right that would be 32 terabytes I think... )

that's the way i understood it as working, although the cluster size doesn't have to be 32 kB. I think it's usually a bit smaller. As for where to find the info, i think you should be able to get it under the properties thing too. wait, no you can't, atleast not in 2k pro. Sorry i don't remember how now

 

[Alphathree33]

I don't claim to be someone who designs storage devices (not yet, anyway ) but now that I think about what I just said, I thought about WHY it might be done like that.

I assume that it is done so that searching for a file can always be done by going through index points that occur at a regular frequency (the cluster size)

But let's say that you designed a hard drive that stored a 1281 bit file on 1281 bits of space and started the next file at the 1282 bit (I'm thinking linearly here for simplicity)... Now you could have another small spot on the hard drive with an index that contained the starting point for each file. No wasted space, and the space the index takes up would be minimal. Why doesn't this work? (I mean, I"m assuming IBM engineers have already thought of this two decades ago... )

EDIT: Refining my thoughts here... more generally speaking if a file is n bits right now, it will take up cluster_size * [(n div cluster_size) + 1] bits, right? Instead, I'm saying have a file take up n bits, start the next file at n + 1 bits and store the point between n and n + 1 in an index.

 

[notfred]

Open "C:\" in explorer. Hit Ctrl+A to select all. Right click on anything that's highlighted. There you go, you get both numbers.

 

[kuk]

I wish I had homework like that ...

Kuk

 

[Alphathree33]

Originally posted by: kuk
I wish I had homework like that ...

Kuk

I know, eh? It doesn't quite compare to doing integration for three pages and stopping because your finger is beginning to hurt...

It's too bad they didn't ask for the "storage space of your processor" (the smart arse answer would be L1 and L2 cache size) or some other extremely misguided question that you hear from newbies. (They want a number, they just dont know what to call the number.)

 

[diskop]

Originally posted by: MajesticMoose

Originally posted by: Alphathree33
I could also be very wrong, but I believe that regardless of the size of any given file, it will always take up at least one cluster. (For example 32 kB)

So if you had a billion 1 kB files, they would still take up 32 billion kB on disk (errrr, right that would be 32 terabytes I think... )

that's the way i understood it as working, although the cluster size doesn't have to be 32 kB. I think it's usually a bit smaller. As for where to find the info, i think you should be able to get it under the properties thing too. wait, no you can't, atleast not in 2k pro. Sorry i don't remember how now

I'm pretty sure it's 4k under FAT32, not sure what it is with NTFS