3

Linux環境である段階で低レベルのディスク操作を実行するアプリケーションを書いています。アプリは実際には2つの部分で構成されています。1つはWindowsで実行され、ユーザーと対話します。もう1つは、LiveCDから実行されるLinuxの部分です。ユーザーがWindowsドライブ文字を選択すると、Linuxパーツが対応するパーティションでアクションを実行します。問題は、Windowsのドライブ文字（C :など）とLinuxのデバイス名（/ dev / sda1など）の一致を見つけることです。これは私が醜いと評価している私の現在の解決策です：

  • パーティション情報（つまり、ドライブ文字、ブロック数、ドライブのシリアル番号など）をWindowsの事前定義された場所（つまり、システムパーティションのルート）に保存します。

  • / proc/partitionsからパーティションのリストを読み取ります。SCSIまたはIDEハードドライブのメジャー番号と、ディスク全体ではなく実際のパーティションとしてそれらを識別するマイナー番号を持つパーティションのみを取得します。

  • ntfsまたはvfatファイルシステムのいずれかを使用して、それぞれをマウントしてみてください。マウントされたパーティションにWindowsアプリによって保存された情報が含まれているかどうかを確認します。

  • Windowsアプリによって書かれた必要な情報を見つけたら、実際に一致させます。/ proc / componentsで見つかった各パーティションについて、ドライブのシリアル番号（HDIO_GET_IDENTITY syscallを介して）、ブロック数（/ proc / componentsから）、およびドライブオフセット（/ sys /blocks/drive_path/partition_name/start）を取得します。これをWindowsと比較します。情報とこれが一致する場合-Linuxデバイス名と一緒にWindowsドライブ文字を保存します。

このスキームにはいくつかの問題があります。

  • これは醜いです。Windowsでデータを書き込み、それをLinuxで読み取ると、テストが悪夢になります。

  • Linuxデバイスのメジャー番号は、IDEまたはSCSIデバイスとのみ比較されます。これはおそらく失敗します。つまり、USBまたはFireWireディスクでは失敗します。これらのタイプのディスクを追加することは可能ですが、アプリを可能なデバイスの既知のサブセットのみに制限することは、かなり悪い考えのようです。

  • HDIO_GET_IDENTITYはIDEおよびSATAドライブでのみ機能するようです。

  • / sys / blockハックは、IDEまたはSATAドライブ以外では機能しない場合があります。

このスキーマを改善する方法について何かアイデアはありますか？おそらく、Windowsアプリにすべてのデータを書き込まずにWindows名を決定する別の方法がありますか？

PSアプリの言語はC++です。これは変更できません。

4

6 に答える 6

2

パーティションには UUID が関連付けられています

これについての私の知識は非常に浅いですが、世界の 99% がまだ固執している古いスタイルの MBR フォーマットではなく、GPT (Guid Partition Table) パーティションでフォーマットされたディスクにのみ当てはまると思いましたか?

于 2008-08-20T22:53:12.067 に答える
1

パーティションにはUUIDが関連付けられています。Windowsでこれらを見つける方法はわかりませんが、Linuxでは次のように各パーティションのUUIDを見つけることができます。

sudo vol_id -uデバイス（例：/ dev / sda1）

Windowsに同等の機能がある場合は、選択したパーティションのUUIDを保存し、Linuxのすべての既知のパーティションを反復処理して、UUIDを一致させることができます。

編集：これはLinuxのみのものである可能性があり、特に、ドライブのメタデータを読み取る代わりに、何かからこれらを生成するvolidutilである可能性があります。そうは言っても、volidのソースを取得し、それが何をするのかを確認することを妨げるものは何もありません。

于 2008-08-20T22:20:05.093 に答える
1

これについての私の知識は非常に浅いですが、世界の 99% がまだ固執している古いスタイルの MBR フォーマットではなく、GPT (Guid Partition Table) パーティションでフォーマットされたディスクにのみ当てはまると思いましたか?

Linuxユーザーの決まり文句のようには聞こえませんが、私にとってはうまくいきます.. NTFSパーティションで使用していますが、問題はありませんでした. 編集で述べたように、vol_id 自体がそれらを生成している可能性があります。その場合、特定のパーティション形式に依存することはなく、うねりがあります。

于 2008-08-21T00:38:59.520 に答える
1

パーティションには UUID が関連付けられています。Windows でこれらを見つける方法はわかりませんが、Linux では次のコマンドで各パーティションの UUID を見つけることができます。

sudo vol_id -u デバイス (例: /dev/sda1)

Windowsに同等の機能がある場合は、選択したパーティションのUUIDを単純に保存し、Linuxで既知のすべてのパーティションを反復処理してUUIDを一致させることができます。

それは良い点です、ありがとう！vol_id (udev tarball の一部) のソースを調べたところ、FAT(32) および NTFS では、パーティションの事前定義された場所から読み取られたボリューム シリアル番号を使用して UUUD が生成されるようです。私は、fat32 と ntfs 以外には何も期待していないので、この情報をパーティション識別子として使用することを検討しています。

于 2008-08-21T07:37:10.340 に答える
0

Windowsでは、LinuxでUUIDと一致するように継ぎ目が付けられた「NTFSボリュームシリアル番号」を読み取ることができます。

Windowsから「NTFSボリュームシリアル」を入手する可能性：

  • XP以降のコマンドライン：fsutil.exe fsinfo ntfsinfo C：

  • C++で

    HANDLE fileHandle = CreateFile(L"\\\\.\\C:", // or use syntax "\\?\Volume{GUID}" 
                               GENERIC_READ,
                               FILE_SHARE_READ|FILE_SHARE_WRITE,
                               NULL,
                               OPEN_EXISTING,
                               NULL,
                               NULL);
DWORD i;
NTFS_VOLUME_DATA_BUFFER ntfsInfo;
DeviceIoControl(fileHandle, 
                FSCTL_GET_NTFS_VOLUME_DATA, 
                NULL, 
                0, 
                &ntfsInfo,
                sizeof(ntfsInfo), 
                &i, 
                NULL));
cout << "UUID is " << std::hex << ntfsInfo.VolumeSerialNumber.HighPart << std::hex << ntfsInfo.VolumeSerialNumber.LowPart << endl;

LinuxでUUIDを取得する可能性：

  • ls -l / dev / disk / by-uuid
  • ls -l / dev / disk / by-label
  • blkid / dev / sda1
于 2010-02-03T18:13:01.327 に答える
0

なんらかの方法でドライブをマークする (たとえば、ファイルを書き込むなど) か、その特定のドライブにのみ関連付けられている識別子を見つける必要があります。

実際に Windows を実行せずに、Windows が特定のドライブ パーティションにどの文字を割り当てるかを判断することは非常に難しく、ほぼ不可能です。これは、Windows が実行元のドライブを常に C: に関連付けるためです。複数のオペレーティング システムがインストールされている場合、どのドライブでもかまいません。Windows では、特定のパーティションに対して最初に試行するドライブ文字を選択できるため、さらに問題が発生します。

このウィンドウと Linux の混合ソリューションを試すよりも、Linux 内で GUI を実行する方がはるかに簡単です。この方法を試してはいけないと言っているのではありません。私が言いたいのは、このアプローチには非常に多くの落とし穴があるということです。私はそれらすべてについてさえ知らないと確信しています。

もう 1 つのオプションは、Windows 内で実際に Linux の部分を実行できるかどうかを確認することです。あなたが非常に優れた Windows プログラマーであれば、生のファイル システムに実際にアクセスすることができます。このすべての操作中に Windows が実行されるため、このアプローチにはおそらく同じくらい多くの落とし穴があります。

繰り返しになりますが、可能であれば、Linux 内からすべてを実行できるかどうかを確認します。長い目で見れば、はるかに単純です。

于 2008-08-21T00:49:58.930 に答える