/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