Hi
I have several computers with the relevant part of the file tree identical- so I can work at any of them and extract the files I've just modified or created, either to removable drive or to remote server. I then update the "master" computer when convenient. I use cpio for this.
Occasionally, I want to take a good look at some of the files before copying them to the "master". This has been tricky- in the end, I found that peazip allows extraction of cpio archives (etc) to any specified path.
I am aware of cpio creation with relative path names- maybe this will allow greater flexibility when restoring, but might be less successful at keeping the various servers identical. (I want to avoid having servers running needlessly, so haven't used the various sync options.)
Is there a commandline method of extracting absolute path cpio archive to a "safe" directory for viewing? Or should I continue to use peazip? -thanks

Create a temporary directory for the cpio archive into, say
To extract the contents under that directory, use
or, if it is a gzipped cpio archive, use
The --no-absolute-filenames makes sure the contents are extracted under the current directory (i.e. using relative paths).

After you're done, just remove the temporary directory:
The sudo above is only needed if it is important to keep the file and directory ownership as defined in the archive. If you are only interested in the file contents, you can drop the sudo from all of the above commands. For example, you can examine initial ramdisks (/boot/initrd*) as a normal user. (Just remember not to pack it back into a new cpio archive, because the user, and not root, will own all files and directories.)

1 members found this post helpful.

Thank you, that was exactly what I wanted... I'm a little surprised that I couldn't find the --no-absolute-filenames argument on my own. It's also made me think about the use of sh -c with && - I'm assuming that && is is used either within a script or a alias and therefore requires sh -c?

In POSIX and Bourne shells, && is an operator that can be read as "and if successful, then".

The idea behind
is that the entire sh scriptlet (the part in single quotes) is run as root, and that some-command ... is run only if the cd command succeeds. If /some/directory cannot be entered, some-command ... will not be run.

Because current working directory is a per-process concept, using
is not the same thing; it changes the working directory in the original shell first. After the command is run, the working directory has changed to /some/directory in the original shell.

Using the sudo sh -c 'cd ... && command' construct, the working directory is only changed in the subshell running as root, not in the original shell. During and after the command is run, the working directory for the original shell does not change at all.

(Using sudo cd /some/directory && some-command ... would change the directory as root in a sub-shell, but the sub-shell would immediately exit. The some-command ... would be run in the original shell, and not with root rights.)

In other words, because I have a command or commands I'd like to run, as root, using a POSIX or Bourne shell, I use sudo sh . The -c '...' is actually a parameter to sh, specifying the commands it should run.