I have what I hope is not a huge problem, but could end up being a very large problem. For some context, I mistakenly ran this command on my 27 iMac:sudo dd if=ubuntu-rescue.img of=/dev/sdt bs=1mafter which, it gave me the following output:233+1 records in233+1 records out244570112 bytes transferred in 2.275065 secs (107500277 bytes/sec)The problem is, that I was NOT INTENDING to move the ubuntu-rescue.img to the location of /dev/sdt. Yikes!What I am trying to do now, is figure out what the original contents of /dev/sdt/ was (before I erroneously wrote data to that file), and if there is a way to inspect the contents (to either delete the disk image that was mistakenly copied there, or in some way restore the contents of /dev/sdt back to its original state).Also, would this dd command erase everything that was there before, or just add data to it?The main problem for me right now, is that I am unaware of what /dev/sdt is (is it a file? a driver? a mounted drive? etc..), so I have no way of knowing how to inspect the damage that was done. So I need to understand what I am looking at when I run this command:ls /devand how to inspect/access/read the contents of these files. Can someone please help me?~~~~~~~~~~~~~~~~~~~~For some further analysis, here are various output from various commands:Not a directory:$ cd /dev/sdt-bash: cd: /dev/sdt: Not a directorySpecial Character file$ file /dev/sdt/dev/sdt: character specialVerbose ls output:$ ls -l /dev/sdtcrw-rw-rw-  1 root  wheel    0,   0 Dec 28 14:02 /dev/sdtSize of /dev/sdt$ du -sk /dev/sdt0   /dev/sdtI 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 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 listing to your very helpful discussions, and reading more on an another (separate, but closely-related) question of mine here on U&L, I discovered that my question has already been asked, so for anyone wanting to read more on this discussion, you can look here.
How to inspect the contents of /dev/sdt?
ls;devices;dd
I was surprised to discover that my Mac Book Air does have a /dev/sdt character special device. Since I could not fathom its nature, I looked up my copy of Mac OS X for Unix Geeks. At page 60, there is the list of all entries in /dev. sdt is indeed mentioned, with the unenlightening explanation:sdt                UndocumentedIt is its only mention in the whole book. So, first of all it is not a storage device. And second, it is unlikely you will manage to do anything with it. At the same time, I cannot see any real reason to worry. 