[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp hangs when copying pipes

From: Bob Proulx
Subject: Re: cp hangs when copying pipes
Date: Tue, 2 Apr 2002 23:36:41 -0700

Thank you for your report.  It was most excellently stated and reports
such as your are most appreciated.  However the behavior you are
seeing is expected and used to this effect by other programs.  I do
not believe it should be changed as it would break programs that
depend upon this working like it does and it would leave them without
an important capability.

> To reproduce:
>   mkdir /tmp/zzz
>   mknod /tmp/pipe p
>   cp -dpuxv --parents --backup=numbered /tmp/pipe /tmp/zzz
>   /tmp -> /tmp/zzz/tmp
>   `/tmp/pipe' -> `/tmp/zzz/tmp/pipe'
>   <hangs here>

At this time your cp command is not hung but rather is trying to copy
the contents of the file which is a named pipe.  This has blocked
waiting for input into the pipe.  Other programs can write into that
pipe and the output will be copied by the cp command.

For an experiment, from another window which this is blocked above try

  echo hello world > /tmp/pipe

You should find that the file is now copied and the contents are the
output of the echo command which was redirected into the pipe.

This behavior is frequently used by randomizing quotation signature
generators.  I am sure you have seen many of those random quotes at
the bottom of people's email messages.  Instead of making ~/.signature
a file it is made a pipe and programs copy the contents into the mail
message.  The contents are made to change with each reading of the
file/pipe by having another program sit in a loop writing random
quotations into it.  Silly.  But very common.

> Oddly, this invocation does work:
>   cp -auxv /tmp/pipe /tmp/zzz
>   `/tmp/pipe' -> `/tmp/zzz/pipe'

The -a option is the key.  It says to copy all attributes of the file
as it sits.  This is also called an archive mode.  Which is to say
symbolic links are recreated and pipes are recreated.  It is useful to
compare the behavior with pipes to the behavior with symbolic links
both with and without the -a option.  The -d option only specifies
symbolic links and pipes are not symbolic links.  You probably want
the -a option instead of the -d option.  The documentation is a little
unclear in this area and could be improved.  (I also noticed that the
-u option is not documented in the info pages.)  The -a option is a
GNU extension and one that has proved extremely useful.

Since we are discussing cp and pipes we should point out another area
of contention.  This issue also pops up in relation to the -r option.
Traditionally the -r option to copy a tree of files would always copy
the contents of the file as in the first case.  Which means that if a
directory contained a pipe it would block there.  However some
operating systems modified cp to avoid this when using the -r option
because it was not seen as being as useful in that context.  Therefore
the -r option is somewhat of a portability problem with repect to
copying trees if they contain named pipes.  Some do one thing and some
do others.  The standard therefore stated that it was implementation
defined behavior.

Therefore the -R option was introduced which would have a "new"
behavior which would never copy the contents, avoiding blocking on
pipes, but would recreate the pipe in the new tree.  Portable
applications should use the -R option.  GNU cp has been in a tug of
war and some versions of -r do one thing and others do another.  I
believe the newest behavior of -r is now identical to the -R option
which is probably the most useful and practical implementation.

> This is fileutils 4.1 from Redhat rpm fileutils-4.1-10.i386.rpm
> running on linux 2.4.18 with low latency patch

Hope this helps


reply via email to

[Prev in Thread] Current Thread [Next in Thread]