|
From: Enrique Perez-T. <en...@on...> - 2005-11-21 01:22:40
|
On Sun, 20 Nov 2005 15:09:49 +0100, Anton Altaparmakov <ai...@ca...> wrote:
> On Fri, 18 Nov 2005, Enrique Perez-Terron wrote:
>> I have a NTFS partition that I cannot locate on the disk when running Linux.
>>
>> I used Disk Manager (or is it "Disk Management", in Computer Management
>> in the control panel) to format a logical partition previously containing
>> an ext3, with ntfs, and I specified a mount point "Program Files". I
>> copied into it the contents of a former "Program Files" directory which
>> I had renamed out of the way.
>>
>> When running W2k, everything works, and I can open e.g.,
>> /Program Files/MinGW/SysM/doc/COPYING, which begins "GNU GENERAL PUBLIC
>> LICENSE" in ascii.
>>
>> However, in Linux, the partition is still type "83 Linux", and "file -s
>> /dev/hdb10" says ext3.
>>
>> I wrote a small C program to search through the sectors of the partition,
>> and look for "NTFS ". No hit. Then I modified it to search for "Microft"
>> in Unicode, case insensitively, since several directories have names
>> starting with "Microsoft". No hit. Testing the same program on other
>> partitions does give hits. The same program is also capable of searching
>> the whole disk /dev/hdb, but still no hits except that "NTFS " occurs
>> in the source of the program, and that one is found in the correct
>> partition. Searching for "GNU GENERAL PUBLIC LICENSE" in ascii, no hits.
>>
>> What could the explanation be?
>>
>> Perhaps there is no NTFS_BOOT_SECTOR when the fs is to be mounted, not
>> given a separate drive letter?
>>
>> I am not aware of any "compression" setting on the file system, I don't
>> even know where I would set that. I suppose compression would only affect
>> file contents, explaining the failure to find "GNU" etc, but how about
>> "NTFS " and the directory names?
>
> The fact that you cannot find NTFS string is odd. Have you checked in
> disk manager in windows that c:\Program Files really is the partition you
> think it is rather than just your original system disk (maybe you did
> something wrong)?
Well, when running W2k, Program Files appears with a disk icon istead of
the usual folder icon, in Windows Explorer. I also know I had the contents
appear two places in the file hierarchy after I copied the data. Before
I copied the data I did "explore" the newly mounted but empty Program Files,
and it was indeed empty.
> Other than that what does an fdisk -ul /dev/hdb say from Linux?
Disk /dev/hdb: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders, total 398297088 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 63 176714 88326 83 Linux
/dev/hdb2 146800640 398297087 125748224 5 Extended
Partition 2 does not end on cylinder boundary.
/dev/hdb5 146800703 148897855 1048576+ 82 Linux swap / Solaris
/dev/hdb6 148897919 150995071 1048576+ 83 Linux
/dev/hdb7 150995135 192938175 20971520+ 83 Linux
/dev/hdb8 192938239 234881279 20971520+ 83 Linux
/dev/hdb9 234881343 276824383 20971520+ 83 Linux
/dev/hdb10 276824447 318767487 20971520+ 83 Linux
Notice:
hdb1 ends on a cylinder boundary. Nothing else is cylinder aligned.
hdb2 extends to the exact end of the disk,
(398297087 + 1) * 512 == 203928109056 == bytes on disk
(but I have strace'd fdisk and seen that it accesses sectors beyond
the data on the disk, so there is either some disk description there,
or that is an interface trick to get data about the disk from the disk
firmware, I don't know.)
There are 73GB (or 69.9GiB, 73311962 blocks) unpartitioned space between
hdb1 and hdb2.
There are 398297087 - 318767487 == 39764800 kiB (37.9Gib) unallocated
space toward the end of the extended partition.
Please use a fixed-width font for this figure:
|hdb5
|hdb1 ||hdb6
|| unpart. ||| hdb7 hdb8 hdb9 hdb10 unalloc
||.........................|||.......|.......|.......|.......|..............|
> Maybe when you did the ntfs partition you did not delete and create again
> the partition but just formatted it? If so it is possible Windows did not
> update the partition type to 7 (NTFS) and left it to 0x83 (Linux). If
This certainly seems to be the case.
I am not 100% sure I remember what exactly I did, I only know I did use
the Disk Management program, and I *believe* I decided to use an existing,
but otherwise never used, partition hdb10, which was formatted earlier
as ext3. The alternative was to make an additional parition in unallocated
space. The fact that "file -s /dev/hdb10" says "/dev/hdb10: Linux rev 1.0
ext3 filesystem data (large files)" suggests the former, quite strongly.
In Disk Manager, the disk layout shown above appears, and clicking on the
/Program Files partition (in the list of partitions in the upper half)
grays the hdb10 part of the diagram. The graphic shows the sizes of the
regions, with 37.9G(i)B in the unallocated space.
> that is the problem just fire up fdisk /dev/hdb and change the partition
> type like so:
>
> $ fdisk /dev/hdb
> t <- t = change partition type
> 10 <- assuming it is hdb10
> 7 <- type 7 is ntfs
> p <- print partition table so you can verify it did the right thing
> w <- write the partition table to disk and exit fdisk
>
> Now reboot and it should be fine.
>
> Note "file /dev/hdb10" may still tell you ext3. But just try mounting
> using ntfs on Linux "mount -t ntfs /dev/hdb10 /mnt/ntfs" and if that works
> everything is fine. The reason it may be detected as ext3 is that
> formatting a partition does not erase the old data. And NTFS in
> particular only erases the first 8kiB of the disk and then only writes way
> into the disk. That means the ext3 metadata at the beginning of the disk
> is still there so when an application looks for it, it can still see it.
>
> You have to be very careful about such things as if you told Linux to
> mount this partition as ext3 it probably will succeed and trash the NTFS
> data in the process...
Thanks, I think I understand the issues here. I guess that the two file systems
have different amounts of leading unused space (reserved for boot loaders etc.)
and so any magic numbers and "superblock" data may appear in different locations
and therefore can coexist.
I also wonder if Windows has offset the start of the file system to a cylinder
boundary. That could explain some, but not all the difficulties in detecting
the file system.
-------------------
Now, since I posted, more has happened, no less alarming.
(I would have avoided any changes while investigating, but I saw no responses for
48 hours and decided I was on my own.)
I decided to backup the various partitions on the other two disks (each disk about
10GB) using eg.
bzip < /dev/hda2 > /backup/2005-11-19/hda2.bz2
fdisk -ul /dev/hda > /backup/2005-11-19/hda-partition-table
dd if=/dev/hda bs=512 count=130 > /backup/2005-11-19/hda-first-130-sectors
All this did fill up /dev/hdb9 to 78%. It's the first time I write to hdb9
(first time I have it mounted) after creating the Program Files fs.
I created a new file system in the unpartitioned space in hdb, ie.
hdb3, 20GiB.
/dev/hdb3 176715 42119755 20971520+ 83 Linux
Since fdisk said partitions were not in disk order, I hit "f" to fix the
order, and I got the extended partition renamed as hdb3, the new partition
as hdb2.
I then removed the linux partition on hda, and made a new install of
Windows 2000. Booting into the new install went ok.
When I then rebooted into the old install of Windows 2k (on hdc), the
/Program Files partiton was gone.
In explorer, there was still a disk icon next to the directory name, but
if I tried to access it, I got error messages:
C:\Program Files not accessible. This folder was moved or removed.
OK
I started Disk Management, getting an error message about a failing snap-in
in Computer Management, but Disk Management seemed to start fine.
There were only three 20GiB logical partitions, and the free space at the
end was now 57.9GB not 37.9GB.
I thought that perhaps Windows had encoded the location of this partition
relative to hdb2, and I swapped the partition table entries for hdb2 and hdb3.
No change.
(Used a short Perl program with "unpack" to extract the part.table
entries, wrote the modified sector to a file first, ran "od -c" on both and
diff, to check. Wrote the modifed sector to disk using dd.)
Before this new turn of events, I know I booted into Windows on several
occasions to check things were as I believed them to be. Once I booted
just to count once again the number of 20Gb partitions shown in Disk Manager,
to make absolutely sure the Program Files was hdb10, not e.g hdb9.
During all the later stages I took notes on paper as I proceeded. I wish
I had done that at the start! I am asking myself if I remember the hdb10
was missing at first in Disk Manager, and I created a "new" partition
of the same size on top of the one already existing, but invisible to Disk
Manager. This is now more than two weeks ago, and I have tried and
speculated so much since then that everything blends in my memory. Or perhaps
not, but I just know every human memory is fragile and unreliable except
under certain special conditions. Off the top of my hat, answering naively,
I seem to remember that
- I created the partition in "free" space in the extended partition.
- There was some kind of fuzz about it, like I could not make up my
mind about what to do.
- I decided to use the hdb10 partition.
- There were already four 20GB logical partitions before creating this
one, formattted as ext3.
- There were four 20GB logical partitions after that, both in the
fdisk output and in Disk Manager's graphic.
I wrote a perl program to gather the binary data from the partition
tables and write it out, without any interpretation (interpretations
could be specific to e.g. linux' fdisk). I say "a table" about the
four 16-byte entries toward the end of a sector. There is a table in
the extended partition's sector zero, and entry #2 (of 1..4) points
to the next table, relative to the start of the extended partition.
Entry #1 describes a logical partition, relative to the sector containing
the table. Each entry has a start sector address and a sector count.
the count of the #2 entries is in a way useless, but does match the
start+count of the next table's entry #1. However, the table describing
hdb9 has a #2.count larger than that. hdb10's #2 is zero,zero, since
there is no next partition. The #2.count being larger could point to
a different program computing it.
The output goes like:
Part Abs.sector 1.start 1.count 2.start 2.count
5 146800640 63 2097153 2097216 2097216
6 148897856 63 2097153 4194432 41943104
7 150995072 63 41943041 46137536 41943104
8 192938176 63 41943041 88080640 41943104
9 234881280 63 41943041 130023744 41950576
10 276824384 63 41943041 0 0
Part.9's #2.count is 7472 larger than the other. Has this number been
written by Linux' fdisk or by Disk Manager?
Another theory: Could the Program Files have been residing in /dev/hdb9
instead, and been overwritten by the backups? But that partition already
contained an older "hda2.bz2" of some 4GiBs after compression.
Yet another theory: Could Program Files have been residing in the
unpartitioned space near the start of the disk, and been overwritten when
I created the new partition /dev/hdb3? But the graphic in Disk Manager
would have to be misrepresenting the disk layout.
In any case, I have not yet touched the /dev/hdb10 except readonly.
I have not even dared to run ext2.fsck on it because I could not
convince myself that there was a sufficiently "readonly" operation
defined in the manpage.
> When formatting a partition from one type to another it is alwayst safest
> to use the slow format setting, i.e. not quick format, which causes the
> whole partition to be erased to zero first thus the above described
> problems cannot occur.
Thanks, thinking a similar thing, I copied /dev/zero to /dev/hda2 before
creating the new install of windows 2000. However, it is hard to always
remember all the small steps you have to take... (sigh).
> btw. To check whether your program is not detecting it properly, you can
> just run "hexedit /dev/hdb" and you should see "NTFS " at offset 3 into
> the first sector.
I don't have hexedit. I'll look for it, thanks for the tip. However, if
I know what sector to look in, it is easy enough to do
od -c /dev/hdbX | less
or
dd if=/dev/hdb bs=512 count=1 skip=XXXXX | od -c
After all this, fdisk -ul right now says
Disk /dev/hdb: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders, total 398297088 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 63 176714 88326 83 Linux
/dev/hdb2 146800640 398297087 125748224 5 Extended
Partition 2 does not end on cylinder boundary.
/dev/hdb3 176715 42119755 20971520+ 83 Linux
/dev/hdb5 146800703 148897855 1048576+ 82 Linux swap / Solaris
/dev/hdb6 148897919 150995071 1048576+ 83 Linux
/dev/hdb7 150995135 192938175 20971520+ 83 Linux
/dev/hdb8 192938239 234881279 20971520+ 83 Linux
/dev/hdb9 234881343 276824383 20971520+ 83 Linux
/dev/hdb10 276824447 318767487 20971520+ 83 Linux
Partition table entries are not in disk order
-Enrique
|
