TranscendStorejet外付けUSBハードディスクを持っています。これはSSDではなく、回転プレートを備えたメカニカルディスクです。ディスク全体をパーティション化せずにNTFSとしてフォーマットしました。 Linuxでmkntfs
ツールを使用しました。
Linuxマシンに接続すると、システムは2つのパーティション(/dev/sdc
/dev/sdc1
/dev/sdc2
)。ただし、パーティションレスディスクであることがわかっているので、デバイス全体をマウントできます(mount -t ntfs /dev/sdc /mnt
)そしてそれは問題なく動作します。
MS Windows XPマシンに接続すると、システムは2つのフォーマットされていないパーティションを持つディスクを認識し、ディスク全体にもパーティションにもドライブ文字を割り当てません。
MS WindowsにディスクをNTFSスーパーフロッピーとしてマウントさせる方法を知っている人はいますか?
「DriveCleanup」を使用して、古いUSBマウントポイントと残りのデバイスを削除しようとしました。それは役に立たなかった。
ちなみに、私は外部のKingston USB SSDも持っています。これも、パーティション化せずにNTFSスーパーフロッピーとしてフォーマットされています。ただし、これはMSWindowsによって正常に認識およびマウントされます。
私はあなたの問題を再現して説明することができます。そしてそれを修正すると思います。
何らかの理由で、ディスクの最初のセクターは、MBRとして解釈されると、半有効なパーティションテーブルを含みます。どちらのOSも、それがスーパーフロッピーであると想定する理由はありません。
私たちが使用するほとんどのディスクはパーティション化されています。この場合、ディスクの最初の512バイトは マスターブートレコード(MBR) です。 GUIDパーティションテーブル(GPT) でも、レガシーの理由から、最初の512バイトはある種のMBRを形成します。重要なことは、最近のすべてのOSは、ディスクの最初にMBRを見つけることを期待しているということです。
スーパーフロッピーは、ファイルシステムの作成時にパーティションとして扱われたディスクです。この場合、最初の512バイトには ボリュームブートレコード(VBR) が含まれます。これは、パーティションの先頭が通常行うようにです。
一部のファイルシステムは、VBRを使用して重要なメタデータを保持します。 [〜#〜] ntfs [〜#〜] はその1つです。 MBRとVBRの両方にbootstrapコードを含めることができます。起動できないデバイスでは、この「コード」は些細な、保護的な、または非常識な場合があります。明確なパターンがないため、次のことを確実に判断することはできません。 512バイトのセクターはMBRまたはVBRまたはその他のものです。
一般的に、あなたができる最善のことは、適切なフラグメントが正常なMBRパーティションテーブルのように見えるかどうかを確認することです。これがオペレーティングシステムの機能だと思います。残念ながら、このテストに合格するVBRを持つことは可能です。
基本的なMBRレイアウト( ここ から)とNTFS VBRレイアウト( ここ から)を比較してみましょう。
MBR │ byte offset │ NTFS VBR
│ hex / dec │
───────────┼─────────────┼─────────────
│ 0x000 / 000 │ mainly NTFS
bootstrap │ … │ metadata
code ├─────────────┼─────────────
│ 0x054 / 084 │
│ … │ bootstrap
───────────┼─────────────┤ code
partition │ 0x1BE / 446 │
table │ … │
───────────┼─────────────┼─────────────
0x55 │ 0x1FE / 510 │ 0x55
0xAA │ 0x1FF / 511 │ 0xAA
───────────┴─────────────┴─────────────
USBスティックを取り、mkntfs -F -f /dev/sdc
を使用してNTFSスーパーフロッピーを作成しました。このツールは、bootstrapコード領域を含む最初のセクター全体を上書きしました。Windowsまたは別のOSは、しばらくの間MBRであると想定し、パーティションテーブル領域をチェックできます。これにより、次のようになります。
#fdisk -l /dev/sdc
Disk /dev/sdc: 31.5 GB, 31466323968 bytes
64 heads, 32 sectors/track, 30008 cylinders, total 61457664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2052474d
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdc1 ? 6579571 1924427647 958924038+ 70 DiskSecure Multi-Boot
/dev/sdc2 ? 1953251627 3771827541 909287957+ 43 Unknown
/dev/sdc3 ? 225735265 225735274 5 72 Unknown
/dev/sdc4 2642411520 2642463409 25945 0 Empty
Partition table entries are not in disk order
ご覧のとおり、fdisk
は「これはパーティションテーブルのようには見えません」と言うことができます。 Windowsは基本的に同じことを伝え、セクターがVBRであると想定し、その中のNTFS署名を見つけて、最後にマウントします。確かにあなたがたは古いWindows XPこれに問題はありませんでした。また私のKubuntuはdmesg
で報告しました:
sdc:不明なパーティションテーブル
しかしその後、KDEはそれをスーパーフロッピーとしてマウントすることを提案しました。
パーティションテーブルをプローブするツールは、実際にはVBRからbootstrapコードのフラグメントを読み取ることに注意してください。このコードはNTFSが機能するために必要ではありません。hexdump
で確認しました。フラグメントは実行可能コードではありません。このデバイスから起動しようとすると表示される一連のテキストメッセージのように見えます。例:
Press Ctrl+Alt+Del to restart
これは、私が半有効なパーティションテーブルを作成できることを意味し、それはおそらく私がとにかく決して見ることのないテキストメッセージとのみ混乱するでしょう。
そうですね、fdisk
を使用して、有効に見えるパーティションテーブルを作成しました。もちろん、ファイルシステムはスーパーフロッピー上のNTFSだけなので、ファイルシステムのない「パーティション」を指します。
WindowsではXPドライブはほとんどあなたのドライブと同じように動作します。ほとんどの場合、最初のパーティションに文字が割り当てられているためです。私の実際の(スーパーフロッピー)NTFSファイルシステムは新鮮で空ですが、あなたのものではありません。そのセクターの一部は、最初の偽のパーティションのVBRとして解釈されます。私たちのセクターには確かに異なるデータが含まれていますが、これが理由かもしれません。それでも、私はあなたの謎を解いたばかりだと思います。
誰かがあなたのスーパーフロッピーを分割しようとしていて、fdisk
とmkfs
の間で気が変わったようです。
私の場合、パーティションテーブルにゼロを書き込むだけで十分でした。
dd if=/dev/zero of=/dev/sdc bs=1 seek=446 count=64
スーパーフロッピーの「ブートストラップコード」フラグメント全体を復元したい場合は、mkntfs
によって作成された別のNTFSパーティションからコピーできます。
fallocate -l 2MiB tmp.ntfs
mkntfs -F -f tmp.ntfs
dd if=tmp.ntfs of=/dev/sdc bs=1 skip=84 seek=84 count=426
rm tmp.ntfs