Devices – How to Inspect the Contents of /dev/sdt

I have what I hope is not a huge problem, but it 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=1m

After which, it gave me the following output:

233+1 records in
233+1 records out
244570112 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!

I am now trying 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 /dev

and how to inspect/access/read the contents of these files.

What should I do?

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