|
You could include an image of the official t-shirt : Google[^]
|
|
|
|
|
As long as the picture is not @Sean-Ewington in mankini...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Just heard on the Radio they can supply water to a family of four for just £3 a month. That's a lot cheaper than I'm paying - I want to switch.
|
|
|
|
|
That's a good idea - it's a lot less than I pay as well!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
|
|
He got off much too easy!
Does anyone want chicken soup?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Fortunately - for Roy - Lanolin is still a vegetarian...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Colours one short of a deck for the most part (6)
One short of a deck = 51 = LI
For the most part = VERY
Giving LIVERY = COLOURS
98.4% of statistics are made up on the spot.
modified 21-May-18 9:32am.
|
|
|
|
|
shades?
one short of spades?
|
|
|
|
|
Nope
98.4% of statistics are made up on the spot.
|
|
|
|
|
Tracer?
One short of deck: Terrac[e]
Anag: Tracer
Colours: Flow tracer
A tad far fetched but...
... such stuff as dreams are made on
|
|
|
|
|
Nope.
98.4% of statistics are made up on the spot.
|
|
|
|
|
So what was it? I'm stumped.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
"hubris"...
hue (one short) - colours
bris - of a deck... of wait... I read that wrong
|
|
|
|
|
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Duncan Edwards Jones wrote: bris
Care to explain that to a non-Englisher?
... such stuff as dreams are made on
|
|
|
|
|
erm… I shall have to read carefully.. it is a word for a religious ceremony that is only performed on the male children.
|
|
|
|
|
I am about to a complete reformat on my rig, and am saving everything to some external drives. However, it seems although the "Size" and # of files match up, the "Size on disk" is off a little bit. Is this indicative of a drive that is about to fail?
|
|
|
|
|
Hi,
Files can be stored on the drive in multiple ways... here are some examples that will cause differing 'Size on Disk'.
FileA.txt stored on Drive A:
If you store a 1KB file (such as small source code file) on a NTFS partition with 4KB (default) sector size... then the 1KB file has a 4KB 'Size on Disk'. The sector unfortunately has 3KB of wasted space.
FileB.txt stored on Drive B:
If you copy that 1kb file and paste it onto an external drive... and that drive saves the file directly into the $MFT then that 1KB file takes 1KB of space.
Right clicking in Explorer on the file in FileA.txt will have '4KB Size on Disk' and right clicking on FileB.txt it will have '1KB Size on Disk'.
Multiply that 3KB difference by a few thousand small source code files and your folders can have large differences in the size reported on disk.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: FileB.txt stored on Drive B:
If you copy that 1kb file and paste it onto an external drive... and that drive saves the file directly into the $MFT then that 1KB file takes 1KB of space. That 1K in the MFT is spent in both cases, for the metadata. On disk A the total space consumption is 5K, but you won't notice it because the MFT is allocated in huge chunks, one really huge one when the volume is formatted. That 1K entry is just a block within that already allocated file.
Furtermore: If the file metatdata requires, say, 400 bytes, there is only 600 bytes left for file data, and a 1K file won't fit in but requires a separate 4K disk page - or whatever the allocation size is for that disk. On my 32 GB memory stick, for some reason the allocation size is 16K. (I could reformat it, but if I fill it up with 32 GB, that will be with huge files where 8K space loss at the end, on the average, is a drop in the ocean. The benefit of fewer units to retrieve outweighs the space loss.)
|
|
|
|
|
Member 7989122 wrote: That 1K in the MFT is spent in both cases, for the metadata.
You are almost correct.
Any and all files saved on an NTFS partition will result in a 1024 byte MFT entry. So it would be correct to say that all files saved on your NTFS partition have an additional overhead of 1024 bytes for the MFT entry. But if we want to get more technically correct... it *could* result in an additional 2048 bytes if we consider the $MFTMirror.
Member 7989122 wrote: Furtermore: If the file metatdata requires, say, 400 bytes, there is only 600 bytes left for file data, and a 1K file won't fit in but requires a separate 4K disk page - or whatever the allocation size is for that disk.
Correct, what happens in this case is that the filesystem driver saves the file directly into a cluster. If that cluster happens to be allocated at 16K then you'll have 15K wasted. + 1K for the MFT overhead and a possible entry into the $MFTMirror for another 1K.
Keep in mind that the topic here is 'Why does explorer report different 'Size on Disk' sizes?'
The answer is that explorer looks at NTFS cluster size, and also whether or not that file has been saved into a cluster. It will correctly round up to the cluster size to take into account the wasted space. If the file has not been saved into a disk cluster it reports the size of a single MFT entry (only on NTFS). Explorer does not even consider the $MFTMirror or take that into account.
There are even more caveats... on a regular file saved into a disk cluster... Explorer only reports the size of the disk clusters and does not report the 1K MFT overhead.
Best Wishes,
-David Delaune
|
|
|
|
|
Not necessarily.
One possibility is that the cluster size of the disks differs. The cluster size is the smallest unit that Windows will allocate on a disk, and if this differs between the disks, the amount of disk space taken by a file may differ, too.
Another possibility is that the disks don'the use the same file system. If one uses NTFS and the other uses FAT32, the meta data stored for each file differs in size, and so will the total space taken.
Lastly, your old disk may have unused areas within the meta data files - over time, files were deleted, created, and some of the meta data area was left unused. When copying the files to a new disk, any such gaps are eliminated.
If you are still worried, run CHKDSK on the disk. This should tell you if any errors exist. If they do, run CHKDSK /F, which will fix the errors.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: The cluster size is the smallest unit that Windows will allocate on a disk ... because the space for the directory is always the same size, no matter how many sectors the disk has. Things quickly become wasteful when your drive (or partition) is too large and when you have many small files.
I hope I find a good balance when I get to implement my file system on the computer I'm building. 8 bit computers usually have small files, but the 'drives' will be up to 128 Gb.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|