Can you copy a block device (eg; /dev/sda1) using the standard cp command?

Well, yes and no I'd think.

cp copies files. Usually one may have a file structure and that device might be mounted to a point. So the question kind of confuses.

a block device, /dev/sda, will be the raw hw device.
a mount point (entrance to a filesystem, etc) will be on a block device

I thought cp command only worked on regular files (-) and dirs (d), but not special files like block devices, character files, named pipes, etc.

Don't files and dirs have start and end to them, and cp works on that. A block device has no "start" and "end" within a block range that spans 0 to X (however big the device is). How would cp command know where the start and end is of a block device?

"In linux everything is a file"

The debian installation guide uses cp to copy an ISO file to a USB device i.e. /dev/sdx so there should be no reason you can not use it to copy in reverse and it does work.

# cp debian.iso /dev/sdX
# sync

cp there though is reading a file from a filesystem, the iso file has a start and end to it.

When you make block device the source (cp /dev/sdx ./iso.img), how does cp know where the start and end of the block device is?

Doesn't the destination also need a start/end. I am not a kernel person but a block device is basically an abstraction layer between the user and the I/O system calls. I'm guessing the maybe the inode contains that info.

cp does an open() on a file or device, and then read() the data until it gets an EOF. In the case of a device the device driver gives the data and the EOF.

That's interesting, special file devices have just 1 inode, and the inode always says "size:0", so what then does cp read() actually read if the inode info says "no size" and "no blocks"?

In the device inode the major/minor number pair points to a device driver.
The file access calls like open() read() close() ioctl() are redirected to the device driver.

What's wrong with trying it yourself and see what happens ?. Great way to learn.

I can try, yes.

I was just trying to get a better understanding of 'cp' command.
I thought it only worked on inode meta info filetype of reg file or directory.

Is there any actual file with data for items in /dev ? No should be the answer, but for those items to exist there needs to be an inode.

I may just be confused about 'cp' and special "files" (block char pipe, etc).

cp increments read() by bytes, dd increments read() by blocks ?

I actually don't know the correct answer, hence why I am asking.

cp itself does not care about inodes. It has 2 file descriptors, one for reading and one for writing.
Anything which can be read can be copied, including a partition or a full raw disk.
It is not important if the fd is a real file on a filesystem or a virtual file on a virtual filesystem or a remote whatever on a remote real or virtual host, the kernel itself will manage the read and write operation (using the appropriate driver/interface).
From this point of view dd and cp are quite similar, just copy is mainly used for real filesystems and dd is mainly used for other kind of data.

Indeed, cp and dd do much the same thing. It's just that cp has options like recursing into directories, handling file attributes, making links instead of copying, not overwriting existing files, etc., while dd has options suited for copying devices, such as setting I/O block sizes, handling errors, bypassing the kernel's buffer cache, and (especially useful for large transfers) showing the progress of the operation.

Now dd does have the reputation of being dangerous, but that's just because it is typically used to do dangerous things, like overwriting devices. You can say that dd is dangerous because you could easily zero out the wrong device, but really you could do exactly the same thing with cp, it's just that usually you wouldn't be doing that.

1 members found this post helpful.

I will ask a new way.

When a util opens a file and does a read(), the abtraction layer between kernel and device (a driver) has to handle feeding the read() with data, but the kernel holds a mapping of that file, the file is all over the disk (fragmented), but the process just receives the file data, has no clue the where it came from, or how fragmented it was. At some point in the read() there will be an eof, and data will stop flowing back to the process.

read(file) <-->kernel<-->major,minor<-->mapping<-->disk
so start of file, pointers to next block, ... , last block(eof)
That's fairly straghtforward.

When a device block is opened, does the kernel handle read() differently? It must if we are expecting the read() to start at block 0, and end is last block of the actual device, AND, it must read() the device blocks sequentially.

How does the kernel know how to handle read() of a reg-file file differently than read() block-device file ?
I know it was mentioned that inode makes no diff, but is that true? How would kernel know the diff between reg-file or block-device if kernel does not read the info in the inode? open() must invoke kernel to read the inode data, no?

I need to craft a test to copy a storage block device to a file on another storage device, will use 'cp' and 'ddresecue'. If they both do exactly the same thing then each file should have same MD5 SHA hashes.

Tar used to be a way. Why don't you use file by file like rsync or partition copy or such?