The original problem and the only response I got (from Dr. Tom
Blinn) are posted below, but it is a bug in cpio. A sctrace was very
revealing. Among the files fed to cpio are a handful of UNIX sockets.
cpio generates a warning/error message about these socket files and
closes fd 0 but keeps going without trying to re-open std in. The next
open gets 0, which is really a file and not stdin, but the rest of the
program doesn't realize that and now tries to read filenames from one
of the files it supposed to be copying! The first socket file is
relatively early in the list, BUT cpio doesn't fail right away, because
it has an entire buffer (8k) worth of files names from the last read
before it has to read stdin (the now incorrect fd 0) to get more.
Sure enough, when I took the socket files that generated these
errors out of the list...
cpio: /mnt/tmp/.X11-unix/X0 : Unknown filetype
cpio: /mnt/tmp/.TTX_128.120.17.100_0 : Unknown filetype
cpio: /mnt/dev/log : Unknown filetype
cpio: /mnt/dev/binlogdmb : Unknown filetype
cpio: /mnt/dev/printer : Unknown filetype
...cpio copies all of the files without incident.
I can send the sctrace output to anyone who wants it, but
it can be roughly regenerated with
# mkdir /var/tmp/root
# cd /
# find . -mount -depth -print > files
# sctrace -fo cpio.sctrace cpio -pdm /var/tmp/root < files
Look for the close(0) just after the message about
.X11-unix/X0. - you'll see what's going on. It seems like a very
simple logic bug in the cpio code. It shouldn't bail on socket files -
it should keep going (the processes will recrate their own socket files
next time they are started).
I tried some other options, like -e, -u and -V as as long shots
but still got the same results.
find(1) is definitely NOT part of the problem. Find is doing it's
job just fine.
Is this something DEC can put into a repair queue somehow?
_____________________________________________________________________
/ Brian C. Hill bchill_at_bch.net
http://brian.bch.net \
| Systems Programmer University of California, Davis |
| Unix Specialist BCH Technical Services |
======================================================================
From: "Dr. Tom Blinn, 603-884-0646" <tpb_at_zk3.dec.com>
To: bchill_at_bch.net (Brian C Hill)
Subject: Re: DU 4.0B +6 - "# find . -mount -depth -print | cpio -pdm /mnt"
Date: Mon, 23 Feb 98 18:05:24 -0500
> Hello Managers,
>
> The "find/cpio" method of copying files works great on
> SunOS 4 & 5 - it maintains timestamps, permissions, ownership and file
> types. But it has never really worked on Digital Unix. I always get
> some kind of an error when I do it either of these two ways:
>
> # cd /
> # find . -mount -depth -print | cpio -pdm /mnt
>
> or
>
> # cd /
> # find . -mount -depth -print > files
> # cpio -pdm /mnt < files
>
> The last few lines of the error are:
>
> .
> .
> .
> /mnt/sbin/advfs/mountlist
> /mnt/sbin/advfs/mssh
> /mnt/sbin/advfs/shblk
> /mnt/sbin/advfs/shfragbf
> cpio: gitout:load_kk:c_install:getsysname:getpasswd:gettimezone:getdate:load_usr_pak:tunesys:doconfig : No such
file or directory
> 32284 Blocks
>
> (those are all files in /sbin/it.d, but that doesn't trigger
> any ideas for me).
>
> BUT, when I do it this way, it works,
>
> # cd /
> # for i in `find . -mount -depth -print` ; do
> # ech "$i" | cpio -pdm /mnt
> # done
>
> it works fine (obviously this is the stupider way, invoking cpio
> hundreds of times), which means that it probably isn't any one file
> that is causing the problem. Why is this? What _IS_ going on? Is cpio
> having a problem with lists of filenames?
>
> I usually use "cp -Rp /a /b", which works well under Dig Unix
> (The SunOS cp won't do symlinks right or ownership - the xpg4 cp's -R
> will do ownership right, but still not symlinks), but I needed to be
> able to use "-mount" to copy only stuff on the root partition, which
> you obviously cannot do with cp -Rp.
>
> Am I missing something about cpio?
That is REALLY WEIRD. Look at the file /sbin/it.d/data/options.data -- the
line you show where cpio is failing is the contents of that file. So the
real question is, what fed the contents of that file, instead of a pointer
to the file, to cpio?
You say that for the second example, where you do the find into a file and
then feed the file into cpio, that it gets the same error. Is there a line
in the file with that text? If not, it's a cpio bug, if so, then it's got
to be a find bug, either way there's some breakage.
On V4.0D, I did a find of just the /sbin/it.d directory hierarchy, and find
did NOT put that line in the file. Same on V4.0B. So I wonder why cpio is
doing whatever it's doing. That is, why is it trying to read that
particular file as a list of files to be dumped, instead of dumping the data
to the device? Weird..
Tom
Received on Wed Feb 25 1998 - 09:45:41 NZDT