When viewing details of a file using Finder, different values are shown for how much space the file occupies. For example, a file takes up 28.8KB of RAM but, 33KB of the disk. Anyone know the explanation?
Disk space is allocated in blocks. Meaning, in multiples of a "block size".
For example, on my system a 1 byte file is 4096 bytes on disk.
That's 1 byte of content & 4095 bytes of unused space.
Related
Im analysing a PE exectuable, i want to know why the physical size is less than the virtual size for the second section?
00000FEC and 00000E00
Exactly what is the Physical size and how is it calculated? Sometimes its more than the virtual size, sometimes its less than the virtual size
# Name VirtSize RVA PhysSize Offset
1 .text 000C44C1 00001000 000C4600 00000800
2 .data 00000FEC 000C6000 00000E00 000C4E00
3 .rsrc 00000520 000C7000 00000600 000C5C00
4 .reloc 0000B098 000C8000 0000B200 000C6200
The virtual size represents the "actual" size of the section, once it has been mapped to memory, whereas the physical size is the number of bytes allocated in the PE file for the section data. Note that the physical size is always a multiple of the file block size (512 bytes), so it might contain some padding bytes after the bytes that correspond to actual section data.
If the physical size is larger than the virtual size, it is precisely because the section data is padded out to a multiple of the file block size (you can see that the difference in size will be less than 512 bytes).
If the virtual size is larger than the physical size, it is because the section ends with zero/null-bytes, and the zeros are not represented explicitly in the PE file to save space.
I have a file on Windows machine with this size and i need to caclulate file size on disk from file size:
Size
3,06 MB (3.216.171 bytes)
Size on disk
3,07 MB (3.219.456 bytes)
I have 512 bytes/sector file system
How to calculate how many sectors I need to use, to store the file from file size?
I understand 3219456 / 512 = 6288, but how to calculate size on disk from file size?
Thare is a way to get size on disc from file size?
I miss something?
Your file length is 0x31132B.
The required storage (rounded up to the nearest cluster) is 0x312000. Your clusters are either 4kB (0x1000) or 8kB (0x2000).
This can be computed as:
clusterSize * ceil(fileSize * 1.0 / clusterSize)
(The 1.0 prevents integer division.) In integer math, it is:
clusterSize * (1 + (fileSize - 1) / clusterSize)
You get the cluster size from GetDiskFreeSpace, which you'll need to call anyway to figure out if your file will fit. See this existing answer:
Getting the cluster size of a hard drive (through code)
Of course, other things can affect the true storage used by storing a file... if a directory doesn't have enough space in its cluster for the new entry, if you are storing metadata with it that doesn't fit in the directory, if you have compression enabled. But for an "ordinary" file system, the above calculations will be correct.
When creating a file with zero size, I would like to set the logical size of the file to be bigger than zero size.
One drive shows for dehydrated files Size on disk with zero bytes and the Size
it will be shown to a value that is the bigger than zero.
Can this behavior be done through windows api functions?
Thanks.
Sample onedrive properties window for a file:
I use NtQueryInformationFile with FILE_STANDARD_INFORMATION struct to retrieve the allocation size of file. But for small files it returns incorrect1 result. For example text file with size 1 byte returns 8 bytes allocation size, instead 4096 bytes. Where is problem?
1 I'm assuming that this value is incorrect, because Explorer (on Windows XP Checked Build in my case) the size on disk reports higher figures (4096 bytes for a file with size 1).
file size in EndOfFile member. AllocationSize - this is how many disk space allocated for file -
Usually, this value is a multiple of the sector or cluster size of the
underlying physical device.
what happens when i open a 100 MB file, and insert 1 byte somewhere near the beginning, then save it? does the Linux kernel literally shift everything back 1 byte (thus altering every page), & then re-saves every byte after the insertion? that seems highly inefficient!
or i suppose the kernel could insert a 1-byte page just to hold this insertion, but i've never heard of that happening. i thought all pages had to be a standard size (e.g., 4 KB or 4 MB but not 1 byte)
i have checked in numerous linux/OS bks (bovet/cesati, kerrisk, tanenbaum), & have played around with the kernel code a bit, and can't seem to figure this out.
The answer is that OSes don't typically allow you to insert an arbitrary number of bytes at an arbitrary position within a file. Your analysis shows why - it just isn't an efficient operation on the typical implementation of a file.
Normally you can only add or remove bytes at the end of a file.