☰

/dev/sdtの内容を確認する方法

tag-icon • tag-icon ls devices dd
/dev/sdtの内容を確認する方法

私は欲しいものを持っていますいいえ大きな問題ですが、最終的には非常に大きな問題になる可能性があります。

場合によっては、27インチiMacで誤って次のコマンドを実行しました。

sudo dd if=ubuntu-rescue.img of=/dev/sdt bs=1m

その後、次のような結果が出ました。

233+1 records in
233+1 records out
244570112 bytes transferred in 2.275065 secs (107500277 bytes/sec)

問題は、ubuntu-rescue.imgをその場所に移動する予定はありません/dev/sdt。こんな！

/dev/sdt/これで、元の内容が何であるか（誤ってファイルにデータを書き込む前に）内容を確認する方法（誤ってファイルにコピーしたディスクイメージを削除したり、何らかの方法で復元できるかどうか）を見つけようとしています。内容を/dev/sdt元の状態に）。

またdd、このコマンドは以前に存在していたすべてを削除しますか、それともデータのみを追加しますか？

今私が直面した最大の問題は、それが何であるか（ファイルなのか、ドライバなのか、マウントされたドライブなのかなど）分からない/dev/sdtために発生したダメージを確認する方法がないことです。したがって、このコマンドを実行するときに私が見ているものを理解する必要があります。

ls /dev

そして、これらのファイルの内容をスキャン/アクセス/読み取る方法。

どうすればいいですか？


For some further analysis, here are various output from various commands:

Not a directory:

    $ cd /dev/sdt
    -bash: cd: /dev/sdt: Not a directory

"Special Character" file

    $ file /dev/sdt
    /dev/sdt: character special

Verbose ls output:

    $ ls -l /dev/sdt
    crw-rw-rw-  1 root  wheel    0,   0 Dec 28 14:02 /dev/sdt

"Size of" `/dev/sdt`

    $ du -sk /dev/sdt
    0    /dev/sdt

I ran the same commands from update #1 on a new Mac Mini (that didn't have its `/dev/sdt` drive tampered with `dd`, and it gave me the **exact same** output as I got on the the iMac after I ran the erroneous `dd` command. Does this mean that the /dev/sdt didn't "record" the contents of the dd transfer? Because the "size" of /dev/sdt displays as zero when I run `$ ls -l /dev/sdt`. Could it be that I got lucky and didn't do any permanent damage?

Both of these commands: `$ du -sk /dev/sdt` and `$ ls -l /dev/sdt` give me the same results on the iMac (where the erroneous `dd` command was run) as it did on the untouched Mac Mini, showing that the data stored in `/dev/sdt` reads at 0 bytes. This makes me assume that this drive is a temporary system drive that is not meant to store data, because even after 240 MB of data was erroneously `dd`'d into it, it still reads at zero byes.

Lastly, I was given a good idea (by user frostschutz) to run this command:

    dd if=/dev/sdt of=mystery bs=1M count=234

And compare the results of the "mystery" file with the contents of the ubuntu-resuce.img, and the output from that experimental `dd` left me with a file called "mystery" which was exactly zero bytes. So I am starting to feel confident that I didn't do any lasting damage, and that this drive is always empty.

After listening to your very helpful discussions, and reading more on an [another (separate, but closely-related) question of mine here on U&L][1], I discovered that my question has already been asked, so for anyone wanting to read more on this discussion, you can look [here][2].

  [1]: https://unix.stackexchange.com/questions/176304/why-does-the-unix-system-need-so-many-0-byte-drives-at-dev?noredirect=1#comment291323_176304
  [2]: https://unix.stackexchange.com/questions/18239/understanding-dev-and-its-subdirs-and-files

答え1

私はMac Book Airがあるという事実に驚きました。する一つある/dev/sdtキャラクター特殊装置。私はその性格を理解できなかったので、私のコピーを参考にしました。Unix オタクのための Mac OS X。 60ページにすべての項目のリストがあります。/開発者。特別で特別な扱い実際に言及されていますが、説明はインスピレーションを与えません。

書類のない特別扱いと特別扱い

この本で言及された唯一の人です。

だからまずはストレージデバイスではありません。第二に、あなたはそれで何もする可能性はありません。同時に、私は心配する実質的な理由がないと思います。

答え2

心配しないでください。常に空で、データが重要な場所に移動していないようです。

この問題に直面する場合に備えて本物この種の作業（削除されたパーティションの完全な回復）に最適なプログラムはドライブです。TestDisk（Chrstophe Grenier製作）。あなたはそれをダウンロードすることができますここ。

答え3

imgファイルをsdtに追加した後、システムにどのような欠陥があるのか​​がわかりましたか？

そうでなければ - あなたは安全だと思います。/dev/sdXYZ通常、ファイルを表すストレージLUNです。 sdt は sdx、sdfa、sdlg などの理由で記録されない場合があります。デフォルトでは添付されません。

ファイルのマイナー番号とメジャー番号が0であることを確認しました。したがって、実際にストレージデバイスの場合は接続されません。システムに何らかの欠陥が見つからなかった場合は、imgファイルを宇宙の反対側のブラックホール[別名/dev/null :)]にコピーしたとします。

関連情報