/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