Partitioning a 2tb hd for Windows 7 64 bit

[Mike Tomlinson]

Bye, dude. The research was done, yet you ignore the proof.

You're in a battle of wits with an unarmed man.

Rod Speed FAQ: http://tinyurl.com/883xp7v

 

[Mike Tomlinson]

I never back up the system, only data.

I'm not talking about backups. I'm talking about Windows loading system
files into memory - DLLs, the registry, etc. These can be corrupted by
faulty memory and then are written back to disk in a corrupt state.

 

[Mike Tomlinson]

Funny that my pair of old DEC VAX4000s do have this built into the
hardware.

DEC built some lovely kit. Tru64 UNIX has 'memory trolling', which runs
in the background and detects faulty memory.

http://tinyurl.com/btc6evf

It is rather obvious that you don't know what you are talking about.

It is, isn't it. Rod Speed FAQ: http://tinyurl.com/883xp7v

 

[Mike Tomlinson]

If he loves to troll, then he would feel at home in comp.os.linux.advocacy.

They're welcome to him. He's currently infesting uk.d-i-y where the
locals had him sussed straightaway.

 

[Gene Wirchenko]

They're welcome to him. He's currently infesting uk.d-i-y where the
locals had him sussed straightaway.

Another group that I have followed for years has had periodic
infestations. I see he has recently been posting there, too.

Sincerely,

Gene Wirchenko

 

[Gene E. Bloch]

I'm not talking about backups. I'm talking about Windows loading system
files into memory - DLLs, the registry, etc. These can be corrupted by
faulty memory and then are written back to disk in a corrupt state.

I don't think DLLs get written back to the disk.

They might be written to the swap file and read back, but they are not
written to the Windows directory tree.

 

[Rod Speed]

I'm not talking about backups. I'm talking about Windows loading
system files into memory - DLLs, the registry, etc. These can be corrupted
by faulty memory and then are written back to disk in a corrupt state.

DLLs arent. And there are checks for corrupted registry too.

 

[Rod Speed]

It is a complex situation.

Nope, very simple, actually.

If your program requires a function from a DLL file, it will load the dll
into ram. Then it depends on what the dll function will do... it could be
used to write data to a file, and if the ram that holds the dll got
corrupted for any reason (just one bit not set right) then the file may
not get written correctly,

And its completely trivial for code that needs to ensure that
cant happen to check that that hasn't happened to the code.

Even just a CRC on the code in ram before its executed will ensure that.

but most likely cause a crash. So it would be hard to say what the
outcome would e.

Not if you have enough of a clue to do a CRC
on the code before its executed in ram and
compare that with the CRC of the DLL etc.

Most of the time nothing is noticed tho. The average consumer will
usually not see anything, but one of the "once-in-a-blue-moon" crash or
freeze can happen.

And with code that needs to be complete robust, the
DLL will just be loaded again and when its CRC is correct
in ram, it will be executed and there wont be anything
more than an soft error logged.

In UNIX, when ram starts to get flakey, the kernel panic happens. That
means it is time to start replacing ram (95% of the time anyway).

The biggest problem will be backing up a file that is already corrupted.

Trivial to ensure that it cant ever be corrupted.

A checksum that is done on a corrupted file at that point won't do you
anygood.

But a CRC before its corrupted will.

Banking systems and critical data stores take the necessary steps to make
sure that the data is good.

And they arent actually stupid enough to spend anything
like $10K on the hardware when it can all be done in software.

 

[Mike Tomlinson]

I don't think DLLs get written back to the disk.

It was intended as an example. Any file that gets read into faulty
memory then written back out to disk is vulnerable.

Windows Update -> downloads an updated DLL info faulty memory -> gets
written to disk corrupted.

And what about %systemroot%\system32\dllcache ?

 

[Mike Tomlinson]

It is a complex situation. If your program requires a function from a
DLL file, it will load the dll into ram. Then it depends on what the
dll function will do... it could be used to write data to a file, and if
the ram that holds the dll got corrupted for any reason (just one bit
not set right) then the file may not get written correctly, but most
likely cause a crash.

just as an aside (I'm probably teaching granny to suck eggs here)
Windows has "Windows File Protection" which can be invoked by 'sfc
/scannow'. This will check for corrupted system files.

But I agree that in mission critical applications, it's best to do
error-checking in hardware, identifying memory faults *before* they have
the opportunity to cause corruption.

 

[Oscar]

It was intended as an example. Any file that gets read into faulty
memory then written back out to disk is vulnerable.

Windows Update -> downloads an updated DLL info faulty memory -> gets
written to disk corrupted.

And what about %systemroot%\system32\dllcache ?

If a dll is damaged by any mechanism, windows will see it as a corrupted dll
and will abort
when it is used.