Operating System - HP-UX
1748152 Members
3297 Online
108758 Solutions
New Discussion юеВ

Re: Ignite-UX tar errors.

 
SOLVED
Go to solution
Steven Schweda
Honored Contributor

Re: Ignite-UX tar errors.

> [...] The default is to write out in tar
> format. So as a result you have many of the
> same limitations as if you were to use the
> regular tar command.

Well, there's "tar" format, and then there's
"tar" format. It's been extended repeatedly
over the years, as evidenced by the ability
of GNU "tar" to deal with file names longer
than 100 characters, and files bigger than
8GB. (Eleven octal digits for the file size?
Who writes this stuff?)

> [...] m_t_r does in fact use pax to create
> the tape.

So, unless "pax" claims to be "tar" when it
gets an error, it's hard to explain those
"tar: Cannot add file [..]" complaints,
wouldn't you agree?

My (unfounded) conjecture is that somehow
someone's running "tar" using a "pax" command
line, and the (incompatible) "pax" options
are confusing/annoying "tar". Of course,
that would conflict with the prevailing "bad
file name" theory, but that's how it looks to
me. (But what do I know?)
Bill Hassell
Honored Contributor

Re: Ignite-UX tar errors.

"bad filenames" is perhaps a misnomer. The Ignite/UX list_expander and the various backup tools are trying to be helpful. There is problem at all in creating obnoxious names with special characters and invisible control characters. The problem is that what you see is not what you get unless you are knowledgeable (how to get rid of "--" or ";" files) and remember to use the -b option for ls as well as enclose spaces inside quotes. Unix isn't unfriendly, it is just indifferent. It follows exactly what you type, and assumes that users know the rules.

Personally I like the list_expander and pax/tar warning messages. It gives me a chance to educate users that create them.


Bill Hassell, sysadmin
Steven Schweda
Honored Contributor

Re: Ignite-UX tar errors.

> Personally I like the list_expander and
> pax/tar warning messages. It gives me a
> chance to educate users that create them.

I'm all for education, and if you can get
"tar" (any "tar") to complain about funny
file names which are in the file system but
not on its command line, I'd _love_ to be
educated.

And if you know of a way to persuade
make_tape_recovery to reveal the "pax" (or
"tar") command(s) it generates, _that_ might
be _particularly_ educational.

> [...] the various backup tools are trying
> to be helpful. [...]

Trying but not succeeding? Or are you saying
that it's more helpful to blow up in this
situation than it would be simply to get the
job done and be quiet about it? Perhaps this
is some new meaning for "helpful", with which
I'm unfamiliar.

This whole "bad filename" thing sounds to me
like a bit of folklore with no foundation in
fact. Now, I'm open to a good
counter-demonstration which will show just
how wrong I am, but a bunch of hand-waving
about restrictions which don't seem to exist
will not convince me. Surely, it can't be
very difficult to create a small file system,
populate it with (so-called) good and bad
file names, reproduce this failure, and then
remove the "bad" file names, and see how
splendidly everything works. _That_ would
_really_ be educational.

It would also seem to demonstrate that the
official HP-UX backup software is a steaming
pile of something stinky, but I'm willing to
believe that, too, _if_ someone can actually
demonstrate that it really has this rather
severe problem.
Patrick Wallek
Honored Contributor

Re: Ignite-UX tar errors.

OK Here's a very simple example.

I created a file called "abc - de f _"

Now, if I do:

$ tar -cvf test.tar a*
abc - de f _


It works fine.

It will even restore
$ tar -tvf test.tar
-rw-r--r-- wallekp/users 0 2009-01-30 22:17:22 abc - de f _


Now the problem comes in when you try to specify the file name on the command line, which pax/tar does with m_t_r:
$ tar -cvf test1.tar abc - de f _
tar: abc: Cannot stat: No such file or directory
tar: -: Cannot stat: No such file or directory
tar: de: Cannot stat: No such file or directory
tar: f: Cannot stat: No such file or directory
tar: _: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors


Do the errors look familiar?


While Unix allows file names with spaces and other character, it can cause issues.


Steven Schweda
Honored Contributor

Re: Ignite-UX tar errors.

> Now the problem comes in when you try to
> specify the file name on the command line,

Isn't that what I specifically excluded? Why
do you think that I did that?

> which pax/tar does with m_t_r:

It _does_? You know that? Yikes. That
_would_ be a steaming pile. Doesn't it know
about apostrophes? I (yes, even I) do.

> Do the errors look familiar?

Only vaguely. They _are_ different.

I see that "man make_tape_recovery" (11.11)
does mention some restrictions:

[...]
File Names with Non-Printable Characters
Although permissible within HP-UX, it is inadvisable to use characters
that do not have a printable graphic on the hardware you commonly use,
or that are likely to confuse your terminal. Filenames with these
characters cause a warning message to be displayed by
make_tape_recovery. In addition, files that contain these non-
printable characters are not included in the archive.
[...]

I may see the steam beginning to rise...

Of course, I wouldn't consider a space
character to be "non-printable".

I also wouldn't call "make_medialif: ERROR:
Cannot tar and gzip script files; [...]" "a
warning message". But I may be eccentric.

I also haven't yet seen make_tape_recovery
spew the errors (under controlled
conditions), just some elementary shell
globbing problems (which may or may not be
related to what make_tape_recovery actually
does).
Patrick Wallek
Honored Contributor

Re: Ignite-UX tar errors.

What do you want, Steven? Do you want the developers to stand up a shout "we screwed up"?

File names with spaces, non-printable character etc., can cause problems with tar & pax.

My feeling is that when some of these tools were originally written, the developers never thought about spaces and other things in file names. Yes, there have been updates over the years, but the fact remains that in some cases Unix just doesn't deal well with some things. Is there room for more improvement? Absolutely.

However, I wouldn't call pax, tar, or the Ignite product a steaming pile of just because it doesn't handle some issues well.

If you think that little of it, don't use it. If you think that little of HP-UX, why don't you go back to your precious VMS?
Steven Schweda
Honored Contributor

Re: Ignite-UX tar errors.

> What do you want, Steven?

What I asked for: a quick demo that
make_tape_recovery really has trouble with
non-trivial file names. (Blame assignment,
always the most important thing, can follow.)

> File names with spaces, non-printable
> character etc., can cause problems with
> tar & pax.

But they don't, really. They _may_ cause
trouble with a _shell_, but that's not the
same thing as causing trouble with "pax" or
"tar". And characters as simple as spaces
don't need to cause trouble for a shell, if
the file names are handled well.

> However, I wouldn't call [...]

A backup program which can't back up legal
files? Boy, that's sure what I'd call it.

> If you think that little of it, don't use
> it. If you think that little of HP-UX, why
> don't you go back to your precious VMS?

I haven't actually left (HP's, not my) VMS.
I just get out a little more than some folks.

I _don't_ use HP-UX much, mostly testing the
Info-ZIP programs, and some other freeware.
(I just hang around in this forum for the
educational value.)

And I didn't say that HP-UX as a whole was
bad, just the defective backup program (if it
really is as defective as people seem to say
that it is).
Dennis Handly
Acclaimed Contributor

Re: Ignite-UX tar errors.

>tar: Cannot add file -: No such file or directory
>tar: Cannot add file 20: No such file or directory
>tar: Error exit delayed from previous errors

As Steven says, something is wrong here. If ignite uses pax(1) there should be no tar messages. I get:
pax: - : No such file or directory

If you want to see what's really going on, you can use tusc:
tusc -fp -a -o tusc.out make_tape_recovery ...

(Assuming a demon isn't doing the work.)
Bill Hassell
Honored Contributor

Re: Ignite-UX tar errors.

The list_expander and pax/tar issues don't represent HP-UX filesystem standards. I submitted a bug report for list_expander because it could not handle very large volume groups (hundreds of lvols and pvs). Getting it fixed without introducing a new filename bug was a challenge.

Ignite/UX is a fine product, with the functionality conspicuously missing in most other flavors of Unix. But the choice of a patchwork tar or pax for today's Ignite product needs serious attention. Since Ignite/UX is 100% proprietary to HP-UX, the choice of its file backup tool should be unconstrained and fully compatible with any useable files and filenames (in my not so humble opinion). Ignite/UX tries to prevent saving (and restoring) systems with issues. Perhaps flags can be used to filter some of the warnings. Certainly the error messages can at least show the full pathname.


Bill Hassell, sysadmin
Kevin Boatright
Occasional Advisor

Re: Ignite-UX tar errors.

I've looked for files that contain any special characters and either a - or 2*0. I have yet to find any.

I did what Dennis suggested and found this in the output.

[11328] execve("/usr/bin/tar", 0x40039d40, 0x40039de8) ... [entry]
argv[0] @ 0x4001ee60: "tar"
argv[1] @ 0x400219d8: "-cfb"
argv[2] @ 0x400219f8: "-"
argv[3] @ 0x40039d68: "20"
argv[4] @ 0x40039d78: "./opt/ignite/data/scripts/os_arch_post_l"
argv[5] @ 0x40039db0: "./opt/ignite/data/scripts/os_arch_post_c"

I'll continue to search.