我拥有我所希望的不是这是一个大问题，但最终可能会成为一个非常大的问题。
在某些情况下，我在 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 页有所有条目的列表/dev。特殊和特殊待遇确实提到了，但解释却毫无启发性：
特殊和特殊待遇无证
这是全书中唯一提到的。
所以，首先它不是一个存储设备。其次，你不太可能用它做任何事。与此同时，我看不出有什么真正值得担心的理由。
答案2
别担心 - 它总是空的，并且数据似乎没有去任何重要的地方。
以防万一您遇到这个问题真实的驱动器，这种工作（恢复整个删除的分区）的最佳程序称为TestDisk，作者：Chrstophe Grenier。你可以下载它这里。
答案3
将 img 文件添加到 sdt 后，您是否注意到系统出现任何故障？
如果没有 - 我想你是安全的。/dev/sdXYZ通常是代表文件的存储LUN。由于与 sdx、sdfa 或 sdlg 相同的原因，sdt 可能没有记录 - 默认情况下不附加它们。
我看到该文件的次要编号和主要编号均为零，因此如果它确实是存储设备，则它不会附加。如果您没有注意到系统出现任何故障，我想说您只是将 img 文件复制到宇宙另一边的黑洞 [又名 /dev/null :) ]。