'pax' help

[Shane Travis]

This is a continuation of http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x35b73a7b3682d611abdb0090277a778c,00.html wherein I'm looking for help extracting a tar archive that was made with absolute pathnames into a relative disk structure. I'm starting a new message because it's my experience that people don't read/help when you've marked a the 'magical solution' already. :-)

Thank you, Mr. Ferguson, for pointing out this interesting tool. 'pax' looks quite useful.

Still having some glitches, though, and hoping that someone might have seen these and can tell me how they got around them. Included below is the command line and complete output:

--------------------------------
# pax -r -p -s ',//,/rnew/,' -t /dev/rmt/0m -v
USTAR format archive
pax: /rnew/ : Not owner
/rnew/
/rnew/.x11startlog
/rnew/hp-ux
pax: /dev/rmt/0m : This doesn't look like a tar archive
pax: /dev/rmt/0m : Skipping to next file...
/rnew/acse.hsd/bin/acse_halt
pax: /dev/rmt/0m : This doesn't look like a tar archive
pax: /dev/rmt/0m : Skipping to next file...
#

--------------------------------

It seems to have worked on exactly three files, and completely ignored the other 3000 or so. I'm not having any luck finding out what the 'this doesn't look like a tar archive' message means.

Anyone have any experience with this?

[RAC_1]

are you able to list the file contents with tar -tvf.

try this
pax -rv -s '/^\///' < your_tar_file.

This will extract everything in current directory.

If this does not work try

dd if=/dev/rmt/0m of=/your directory
this will copy tar archeive from tape to a directory. Check permissions. if required change them and try the above pax command again.

I am assuming that you are using root id for all this.

Regards,

[James R. Ferguson]

Hi Tim:

A long shot, but seems like worth the question. The Technical Knowledge Base has a document (#RCMEMKBRC00004081) that indicate(d) that tar archives created with filenames with extended ASCII characters in them (beyond ASCII 127) cannot be properly read by pax.

You are seeing:

pax: This doesn't look like a tar archive
pax: tar.out : Skipping to next file...

The document notes this error if you simply do:

# pax -vf tar.out

Does this fit?

Regards!

...JRF...

[Shane Travis]

> are you able to list the file contents
> with tar -tvf.

Yes. I get a complete listing of the tar on the DAT drive.

> try this:
> pax -rv -s '/^\///' < your_tar_file.
>
>
> This will extract everything in current
> directory.

Alright... not quite parsing this. You're suggesting that I use my tar file as an input to pax?

And, re-writing the substitution string to use % as the delimiter instead of slashes... you're recommending '%^/%%' -- right?


> If this does not work try
>
> dd if=/dev/rmt/0m of=/your directory

Another fine idea. Tried it, got this:

# dd if=/dev/rmt/0m of=/rnew/backup.tar
(long wait)
dd read error: I/O error
40653+0 records in
40653+0 records out
# pwd
/rnew
# tar -tvf backup.tar
rwxr-xr-x 0/0 0 Dec 7 15:33 1998 //
directory checksum error


> I am assuming that you are using root id for
> all this.

One of those things it never hurts to ask... but yes I am. Sorry, I _wish_ it could be that easy.

I appreciate the suggestions. Any further feedback also appreciated.

[Shane Travis]

> [...] tar archives created with filenames
> with extended ASCII characters in them
> (beyond ASCII 127) cannot be properly read
> by pax.
>
> Does this fit?

Gyah. That'd be all I need.

Honestly, I cannot think of any non-ASCII characters that would have gone into this tarball. This is a backup of the root directory and the development code (all of which is written in plain ol' English), so unless there's something funky down in the languages section of HP-UX, we _should_ be fine in that regard. Always the possibility of some invisible control character somewhere though, I suppose.

Thanks for the thought; sounds like I'm just plain SOL. It's really weird that it expanded picked that one file properly out of the middle of everything else, though...

[RAC_1]

Just cut and paste following command and give the output. Replace your_tar_file with your actual tar file.

Regards,

pax -rv -s '/^\///' < your_tar_file.

[Shane Travis]

# pax -rv -s '/^\///' < /dev/rmt/0m
USTAR format archive
/
pax: - : This doesn't look like a tar archive
pax: - : Skipping to next file...
#

So it looks like I'm backto the same problem as I initially posted about, and not much of a solution in sight. Thanks a lot for the ideas, though.

[Frank Slootweg]

Your original command

pax -r -p -s ',//,/rnew/,' -t /dev/rmt/0m -v

is wrong:

You specify "-p", but "-p" should have an argument, but you do not specify one.

Also you seem to think that "-t" specifies a tape device, but it means something completely different.

As far as I can tell, you effectively need the third example from the EXAMPLES section of the pax(1) manual page. That example is:

> To read the archive a.pax, with all files rooted in the directory /usr
> in the archive extracted relative to the current directory, enter:
>
> pax -r -s ',//*usr//*,,' -f a.pax

If I understand your question correctly, you should change this example to:

pax -r -s ',//*rnew//*,,' -f /dev/rmt/0m

[Shane Travis]

> Your original command
>
> pax -r -p -s ',//,/rnew/,' -t /dev/rmt/0m -v
>
> is wrong:

Perhaps for your version of HP-UX, but in the post I pointed to (probably should have reiterated that fact here) I'm dealing with a much older version of HP-UX... v8.0, to be exact.

> You specify "-p", but "-p" should have an
> argument, but you do not specify one.

-p Preserve access time of the input files after they have been copied.

I see from an 11.0 machine that now you can preserve different things, so you need a string.

> Also you seem to think that "-t" specifies a
> tape device, but it means something
> completely different.

-t device device is an implementation-defined identifier that names the input or output archive device, overriding the default of standard input for -r and standard output for -w.

... VERY different from the 11.0 version of pax, in which this argument has something to do with access times.


> If I understand your question correctly, you
> should change this example to:
>
> pax -r -s ',//*rnew//*,,' -f /dev/rmt/0m

Last bit is right... I'm trying to take from /dev/rmt/0m (but I need to use -t under my implementation), but the substitution is wrong. I'm trying to replace the '/' directory with '/rnew' ... or with nothing at all. I haven't tried anything that will just use an extraction relative to this point, so it's worth a shot, but I expect that I'll still run into the above problems about not recognizing the tape as a tar arhive. :-(

Thanks for the attempted assistance, sorry for the confusion.

[Frank Slootweg]

Well, I think that the (pax) *documentation* which you have does not match the pax *program* which you have.

Why? You say that for your version "-p" does not take a parameter, but it does give an error message:

> # pax -r -p -s ',//,/rnew/,' -t /dev/rmt/0m -v
...
> pax: /rnew/ : Not owner

So (I think) that pax *does* take /rnew/ to be the parameter for "-p".

Also you say that pax does not recognize the archive, but it does seem to *partially* recognize the archive because it lists some paths from the archive:

> rnew/
> /rnew/.x11startlog
> /rnew/hp-ux
...
> /rnew/acse.hsd/bin/acse_halt

Perhaps you can get short usage instructions from the *program* (instead of from the documentation). For example on 10.20, "pax -?" (complains and) gives short usage instructions.

I am also a little worried about the

> USTAR format archive

line. Perhaps there is a problem of POSIX versus pre-POSIX tar format. See the tar(1) and tar(4) manual pages.

To determine the archive format, just do:

dd if=/dev/rmt/0m of=/tmp/record bs=64k count=1
ll /tmp/record
file /tmp/record
rm /tmp/record

and report the results here, i.e. the output/messages.

You say that this is HP-UX 8.0. Do you have access to *another* newer system, 10.20 or 11.X, where you could extract the archive with pax(1) and rewrite it with relative (i.e. no leading /) pathnames with plain-old tar(1)?

[Shane Travis]

> Also you say that pax does not recognize the
> archive, but it does seem to *partially*
> recognize the archive because it lists some
> paths from the archive:

Yeah, that's frustrating. If it ignored everything, I could just accept that... but it tantalizes me with little bits of unpacking. :-)


> For example on 10.20, "pax -?" (complains
> and) gives short usage instructions.

acsesys server0 26: pax -?
No match.


> Perhaps there is a problem of POSIX versus
> pre-POSIX tar format. See the tar(1) and tar
> (4) manual pages.

Could be, I suppose. The 'tar' was done on a 300-series running 8.0, and the pax is (currently) being run from a G30 running 9.04, since that's the only one with a dat drive any more. (The rest burned out and were never replaced.)


> You say that this is HP-UX 8.0. Do you have
> access to *another* newer system, 10.20 or
> 11.X, where you could extract the archive
> with pax(1) and rewrite it with relative
> (i.e. no leading /) pathnames with plain-old
> tar(1)?

Not on site, no. 8.0 and 9.04 is all they have there... but the tapes don't have to stay on site. I came to the same conclusion yesterday, and am going to get them to FedEx them to me over the weekend. I can work on them locally (use gtar or pax on one of the newer local systems to get them off the dat, then re-tar them with relative pathnames) and FedEx them back within about a week or so. Not optimal, but I can't see any on-site solution that will work any better than that. At least this way I don't have try and build tools so I can build tools that will fix the problem.

Thanks, everyone, for all the help. I appreciate your efforts in working with me on archaic systems like this, and I _did_ learn a new command. :-)

[Frank Slootweg]

Final (?) small point:

> acsesys server0 26: pax -?
> No match.

I think that is a C-shell (or similar) issue. Are you using a C-shell like shell? If so, as far as I know, "No match" is a C-shell error, not a pax one. You probably have to escape the minus or/and the question mark.

[Kelli Ward]

Hi,
Also, there is a cumluative pax patch (PHCO_25418). I didn't notice a fix for the error you mentioned in it's description, but it might be of some assistance, if not already installed.
Good Luck,
Kel

[Shane Travis]

Kelli Ward wrote:
> Also, there is a cumluative pax patch
> (PHCO_25418).

Appreciate it, Kelli, but that's for a newer version of the O/S than I'm running. Thanks anyway for the pointer.


Frank Slootweg wrote:
> You probably have to escape the minus or/and
> the question mark.

Umm... d'oh! I should know that by now.

Anyway, still doesn't work, thus proving how old this version is. :-)


acsesys server0 23: pax \-\?
pax: illegal option -- ?
Usage: pax -[cimopuvy] [-f archive] [-s replstr] [-t device] [pattern...]
pax -r [-cimopuvy] [-f archive] [-s replstr] [-t device] [pattern...]
pax -w [-adHimuvy] [-b blocking] [-f archive] [-s replstr]
[-t device] [-x format] [pathname...]
pax -r -w [-ilmopuvy] [-s replstr] [pathname...] directory


I appreciate all the help everyone offered; the DATs are on their way here, and should arrive tomorrow. Once that happens, it should be a piece of cake to get everything functioning again... especially now that I'm armed with all this new knowledge.

Thanks again.

[Kelli Ward]

Hi,
OK, how about this one?
PHCO_20388 Pax Cumulative patch for s700 and s800 for HP-UX 10.2
Maybe that one will work for you.
Good luck,
Kel