[TriLUG] cp of /dev hangs, but not tar

Jon Carnes jonc at nc.rr.com
Sat Jun 16 12:10:33 EDT 2007


I'm certain that cp does a write then a read to verify... or rather it
calls a disk-write process that does a write then a read before giving
the thumbs up back to the cp process. Of course it's been a long, long
time since I've looked at the source code for cp.

An interesting note from the info pages for cp:
`--copy-contents'
   If copying recursively, copy the contents of any special files
   (e.g., FIFOs and device files) as if they were regular files.
   This means trying to read the data in each source file and writing
   it to the destination.  It is usually a mistake to use this
   option, as it normally has undesirable effects on special files
   like FIFOs and the ones typically found in the `/dev' directory.
   In most cases, `cp -R --copy-contents' will hang indefinitely
   trying to read from FIFOs and special files like `/dev/console',
   and it will fill up your destination disk if you use it to copy
   `/dev/zero'.  This option has no effect unless copying
   recursively, and it does not affect the copying of symbolic links.

And or course, I've done this. Long ago I too once tried to copy the
/dev directory and as I recall the copy took forever, and when I went in
to look I found it copying Zeros to a file ad-infitium...  :-)

Soon there-after I learned about Minor and Major block devices.

Jon Carnes

On Sat, 2007-06-16 at 11:41, James Tuttle wrote:
> Jon Carnes wrote:
> > The items in /dev are not files per say. They are created by the system
> > to help it managed devices. Their is nothing in these "files" rather the
> > important information is stored in the node space. Each named device has
> > a Major and Minor Block number associated with it that identifies that
> > device and what it does. 
> > 
> > Tar handles this well, as it recognizes that you are simply recording
> > the node info and there isn't really any file "data". Maybe we should
> > re-write cp so that it understands that as well?
> > 
> > Jon Carnes
> > 
> > On Sat, 2007-06-16 at 09:19, Joseph Mack NA3T wrote:
> >> Some of my backups involve a disk-to-disk `cp -ruvp`. Some 
> >> files in /dev (eg console, pty*) and a /var/lib/fifo I have 
> >> cause the cp to hang. If instead I tar up that directory, it 
> >> works fine. What's the difference between the read that cp 
> >> does and tar does?
> >>
> >> Most of my machines are 2.4.x. I tried a 2.6 machine
> >>
> >> This doesn't hang
> >> /tmp# cp -ruv /dev/console .
> >>
> >> This hangs
> >> /tmp# cp /dev/console .
> >>
> >> With 2.4, both hang.
> >>
> >> Thanks
> >> Joe
> >>
> >> -- 
> >> Joseph Mack NA3T EME(B,D), FM05lw North Carolina
> >> jmack (at) wm7d (dot) net - azimuthal equidistant map
> >> generator at http://www.wm7d.net/azproj.shtml
> >> Homepage http://www.austintek.com/ It's GNU/Linux!
> > 
> Speaking of how cp works, I've found little to describe how it verifies
> writes.  At work I've written a python process that creates a checksum,
> copies a file, creates a checksum of copied file, compares checksums,
> and retries if checksums don't match.  I would have used rsync since it
> has a checksum flag, but I wanted it to be platform independent.
> 
> My questions is this: Does cp validate writes and how?
> 
> Jim
> 
> -- 
> --
> ---Jim Tuttle
> ------------------------------------------------------
> url: http://www.prairienet.org/~jtuttle/
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x69B69B08




More information about the TriLUG mailing list