Hello David and thanks for posting to the forum. I have to take issue with
your ³bogus info². I work for a specialized industrial PC OEM, where we
build locked down computers that utilize windows XP professional, and
windows XP embedded. So lets go through the numbers here:
My problem with your problem #1:
You are correct that copying a NTFS partition in g4u will fail. This is
because when you copy a partition, you do not copy the master boot record or
the master file table(MBR and MFT respectively). These are stored as you
said, in different areas of the disk from where you would regularly find
partitions. That being said, when you perform the ³uploaddisk² and
³copydisk² commands, the MBR and MFT and ALL partitions are copied,
regardless. This will ensure windows knows exactly what, when, where, and
why stuff is on disk. When copying just a partition, you lose that
guarantee. This is a problem with ALL imaging systems, including those from
the major manufacturers. The only way around it is to read INSIDE the NTFS
partition, and copy files by utilizing the filesystem. This is experimental
though at best in most imaging systems, and I¹m not entirely sure how it
would work when you write it back without modifying the MFT. I¹m sure Hubert
could update the FAQ in that respect about NTFS, but honestly, you should
know your filesystem if you¹re going to be imaging it. I seriously doubt the
website is intended to be the end-all resource on how imaging works, and how
it impacts filesystems.
My problem with your problem #2:
Ok, this one I have a great experience with. So the woman who does the
ordering made a mistake at one point, and ordered 40 gig hard drives instead
of 60s (which is the minimum size that our computers come with). My images
are made assuming a geometry of a 60 gig hard drive. So, I went to image a
bunch of computers, and just assumed it was the right size because well she
had never messed up before, and most of the time its hard to tell from the
manufacturer label what the size of the drive is (especially with seagate
for some reason). Anyway, so I imaged 5 computers using g4u. They all fail,
complaining about running out of drive area, basically. So I looked up the
model number, went and yelled at her, and then thought ³Well my image is
only about 5 gigs in total size² so I tried booting one. And it booted!!
Granted, windows thought there was a 60 gig drive, when really there only
was a 40, and probably would die a horrible messy death as soon as it tried
to write to one of those areas on the drive beyond the geometry of the
current disk, but it works!
I would say I got lucky, but, as long as your drive is not SMALLER than the
drive you made an image from, it will work just fine. I¹ve used 60s from all
of the major manufacturers, and it just works. They all MUST have the same
geometry because, when you add up the sectors and columns, that¹s how you
get a 60 GB drive size. Else they would be improper labeling and false
advertising, and ever since the CRT size debacle (and maybe even before), IT
people have been very good at suing manufacturers for false marketing.
I look forward to your comments.
Matt Smollinger
Application Engineer for Convergence Tech.
AdvancedAV ATG
From: David Balazic <[EMAIL PROTECTED]>
Date: Sun, 23 Sep 2007 15:39:57 +0200
To: <g4u-help@feyrer.de>
Conversation: Bogus info about Windows and NTFS support
Subject: [g4u-help] FAQ: Bogus info about Windows and NTFS support
Hi!
At http://www.feyrer.de/g4u/#filesystems it says :
5.1 Supported filesystems
One of the questions arising a lot is "what filesystems does g4u support".
The answer is: "all of them". g4u reads the disk bit by bit, starting from
byte #0 to the end. It includes any MBR, boot record, partition table and
the partitions themselves without further investigating the structure of the
data stored in these partitions.
For NTFS and Windows, this contradicts itself ;-)
Problem 1 :
If you copy a ntfs partition to another partition (let say on the same disk)
bit by bit, it wont work (at all, or will report errors; in Windows).
Namely, ntfs stores some data related to its position on the disk. After
days of debugging this problem, I found a web site explaining the background
and also how to fix it. Unfortunately, I don't remember the address of that
site. Basically, the start postion of the partition must be stored somewhere
in the ntfs system data sectors, expressed as bytes from the beginning of
the disk (warning, writing from memory).
Problem 2:
If you clone bit by bit a disk to another and it contains Windows, the clone
will probably not work (fail right in the boot loader). This is again,
because the Windows boot system has a dependency on certain crap that you
surely know, called "geometry". Which can be different for different disks.
In this moment, I have no idea how to fix this.
I believe this info would clear up a few things for users cloning Windows
related disks and/or partitions.
Regards,
David
PS: I would be great if you propagate this info to other implementors of
free disk cloning programs, so they can inform they users. (and by that
reduce traffix on their mailing lists; this of course should hold also for
this list)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
g4u-help mailing list
g4u-help@feyrer.de
https://lists.sourceforge.net/lists/listinfo/g4u-help
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
g4u-help mailing list
g4u-help@feyrer.de
https://lists.sourceforge.net/lists/listinfo/g4u-help
