On Fri, May 18, 2001 at 12:18:30AM -0400, Ray Shaw wrote:
On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote:
clip
I can also tell from personal experience that I haven't had trouble
with GNU tar 1.13.17 on GNU/Linux/x86, but I still haven't been able
to do backups reliably
On May 17, 2001, John R. Jackson [EMAIL PROTECTED] wrote:
Looks like gcc 2.8.1.
Gee. That's dead broken. ...
Yeah, yeah. But you're just a wee bit biased :-) :-).
FYI, I've just found this in GNU tar 1.13.19's README:
quote
* Solaris issues.
GNU tar exercises many features that can
On Sun, May 20, 2001 at 04:45:52PM +1000, Jason Thomas wrote:
On Fri, May 18, 2001 at 12:18:30AM -0400, Ray Shaw wrote:
On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote:
clip
I can also tell from personal experience that I haven't had trouble
with GNU tar 1.13.17 on
* John R. Jackson [EMAIL PROTECTED] (Thu, May 17, 2001 at 04:02:19PM -0500)
I was going to stay out of yet another round of dump vs tar, but what
the hell. Here's a little eye-opener for all you tar folks ...
$ gtar --version
tar (GNU tar) 1.13.19
Not to panic you or anything, of
I was never able to compile GNU tar with gcc 2.8.1 on Solaris.
But I work fine if compiled with SUN cc.
I retried my test case using GNU tar 1.13.19 built with Sun cc and
with gcc-2.95.3. Both work fine. So it was a bug with 2.8.1.
I didn't say it very well in the original post, but I was not
On Fri, May 18, 2001 at 11:43:01AM -0500, John R. Jackson wrote:
I was never able to compile GNU tar with gcc 2.8.1 on Solaris.
But I work fine if compiled with SUN cc.
I retried my test case using GNU tar 1.13.19 built with Sun cc and
with gcc-2.95.3. Both work fine. So it was a bug with
Hi,
I just saw that someone had problems with dump and Linux. This made
me remember an posting from Linux Torvalds of a few weeks back which I
think anyone still using dump with Linux should read:
http://www.lwn.net/2001/0503/a/lt-dump.php3
Summary: Dump was a stupid program in the first
right now.
Eric Veldhuyzen wrote:
I just saw that someone had problems with dump and Linux. This made
me remember an posting from Linux Torvalds of a few weeks back which I
think anyone still using dump with Linux should read:
http://www.lwn.net/2001/0503/a/lt-dump.php3
Summary: Dump
On Thu, 17 May 2001, Jonathan Dill wrote:
I'm planning to migrate to SGI XFS on Linux--SGI has released an
installer CD for Red Hat 7.1 which can make XFS filesystems. XFS is a
journaled filesystem, and it can be run over RAID unlike ext3 which had
problems with RAID on 2.2 kernel. You can
Summary: Dump was a stupid program in the first place. Leave it behind.
What it really means: Linux is a toy system and rather than fix our
design flaws we'll play sour grapes.
On Thu, May 17, 2001 at 07:51:09AM -0700, Anthony A. D. Talltree wrote:
Summary: Dump was a stupid program in the first place. Leave it behind.
What it really means: Linux is a toy system and rather than fix our
design flaws we'll play sour grapes.
Yikes! A troll!
--
Yikes! A troll!
Nope, just a naked emperor.
Anthony A. D. Talltree schrieb:
Summary: Dump was a stupid program in the first place. Leave it behind.
What it really means: Linux is a toy system and rather than fix our
design flaws we'll play sour grapes.
wrong.
what it realy means is: dont use a loaded rifle as a walkingstick,
Dump bypasses the filesystemlevel to access the data and therefor only
works reliable if all caches are flushed to disk. This is only garanteed
if the filesystem is unmounted or at least mounted read-only.
Yes, I know. I learned that 15 years ago.
But this is not a problem of linux, it's a
Also Sprach Dan Wilder:
On Thu, May 17, 2001 at 07:51:09AM -0700, Anthony A. D. Talltree wrote:
Summary: Dump was a stupid program in the first place. Leave it behind.
What it really means: Linux is a toy system and rather than fix our
design flaws we'll play sour grapes.
Yikes!
Also Sprach Anthony A. D. Talltree:
Yikes! A troll!
Nope, just a naked emperor.
No, a nakked emperor penguin.
--
C. Chan [EMAIL PROTECTED]
Finger [EMAIL PROTECTED] for PGP public key.
On Thu, 17 May 2001 at 11:09am, C. Chan wrote
I made some backups with Amanda using GNU tar and xfsdump and the recovery
under both was consistent. I followed suggestions to remove ext2 dump so
Amanda would detect xfsdump and recompiled, but I find this rather inelegant.
I plan to make a JFS
On Thu, 17 May 2001 at 8:50am, Anthony A. D. Talltree wrote
Yikes! A troll!
Nope, just a naked emperor.
This Needs To Stop. Now. I have had enough of anti-Linux flamefests, and
I especially do not want to see one on a mailing list with one of the
hightest SNRs I've ever seen.
If you want
Sorry for the newbie question, but how can tar be configured so
that after restoring a full and an incremental the filesystem has
exactly the files at the time of the incremental, not any files
which were present during the full but removed before the incremental.
Thanks,
Ron Stanonik
[EMAIL
On May 17, 2001, Ron Stanonik [EMAIL PROTECTED] wrote:
Sorry for the newbie question, but how can tar be configured so
that after restoring a full and an incremental the filesystem has
exactly the files at the time of the incremental, not any files
which were present during the full but
On May 17, 2001, C. Chan [EMAIL PROTECTED] wrote:
I followed suggestions to remove ext2 dump so
Amanda would detect xfsdump and recompiled, but I find this rather inelegant.
What is inelegant? Removing ext2 dump? You didn't have to do that.
You only need xfsdump available at configure time
On May 17, 2001, Anthony A. D. Talltree [EMAIL PROTECTED] wrote:
But this is not a problem of linux, it's a problem of dump.
Yeah yeah yeah. We've all heard that a million times before, and yet on
real systems we've been happily using dump for years without
consequences.
You've been lucky
On Thu, May 17, 2001 at 05:09:16PM -0300, Alexandre Oliva wrote:
On May 17, 2001, Ron Stanonik [EMAIL PROTECTED] wrote:
Sorry for the newbie question, but how can tar be configured so
that after restoring a full and an incremental the filesystem has
exactly the files at the time of the
I think I was the one who made the suggestion to remove ext2 dump, but I
was wrong, you don't have to do that. ./configure will find both
xfsdump and dump, and amanda will choose whichever program is
appropriate for the type of filesystem i.e. if it is XFS filesystem and
you have not specified
I was going to stay out of yet another round of dump vs tar, but what
the hell. Here's a little eye-opener for all you tar folks ...
$ (umask 077 ; mkdir /tmp/jrj)
$ cd /tmp/jrj
$ rm z.tar zli
$ cp /dev/null zli
$ gtar --version
tar (GNU tar) 1.13.19
...
$ uname -srp
SunOS 5.6
On May 17, 2001, John R. Jackson [EMAIL PROTECTED] wrote:
Oh, shit.
I wouldn't have put it better :-)
I tried GNU tar 1.12 (plus the Amanda patches) and it works fine.
Thanks God I'm still using that one, on most systems I've got. Talk
`conservative' regarding backups.
But if'n I were
On May 17, 2001, Dan Wilder [EMAIL PROTECTED] wrote:
Is this an option amrecover can (or does) pass to tar?
Nope. amrecover explicitly tells tar which files to restore, so this
is not an issue.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
On May 17, 2001, John R. Jackson [EMAIL PROTECTED] wrote:
--listed-incremental /tmp/jrj/zli \
This does what Amanda does for a full dump.
Just to make sure (and for the enlightenment of anyone else trying to
duplicate the problem): you have removed /tmp/jrj/zli before every tar
Just to make sure (and for the enlightenment of anyone else trying to
duplicate the problem): you have removed /tmp/jrj/zli before every tar
command, right? ...
Yes. What I posted was really the list of commands I put into a little
test script. The cp of /dev/null to zli is part of that and
On Thu, May 17, 2001 at 04:02:19PM -0500, John R. Jackson wrote:
But if'n I were you folks using this version of GNU tar, I'd start
making damn sure your tapes had anything even faintly useful on them.
Amverify should do the trick, although I certainly wouldn't stop there.
Not to panic you
On May 17, 2001, John R. Jackson [EMAIL PROTECTED] wrote:
Did you try to read this tar-file with some other tar program? ...
... such as GNU tar 1.12?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com,
Did you try to read this tar-file with some other tar program? ...
... such as GNU tar 1.12?
Same result.
Looks like gcc 2.8.1.
Gee. That's dead broken. ...
Yeah, yeah. But you're just a wee bit biased :-) :-).
First thing I'd do would be to get GNU tar
1.13.19 built with a newer
On Thu, May 17, 2001 at 06:36:16PM -0300, Alexandre Oliva wrote:
On May 17, 2001, Dan Wilder [EMAIL PROTECTED] wrote:
Is this an option amrecover can (or does) pass to tar?
Nope. amrecover explicitly tells tar which files to restore, so this
is not an issue.
Ahh. Good!
Amrecover
On May 17, 2001, John R. Jackson [EMAIL PROTECTED] wrote:
Yeah, yeah. But you're just a wee bit biased :-) :-).
Me! No way! :-D
First thing I'd do would be to get GNU tar
1.13.19 built with a newer compiler. ...
So what's the recommended **stable** gcc these days?
2.95.3
I'll try
On May 17, 2001, John R. Jackson [EMAIL PROTECTED] wrote:
Do you know which compiler was used to build this version of GNU tar?
Looks like gcc 2.8.1.
Gee. That's dead broken. First thing I'd do would be to get GNU tar
1.13.19 built with a newer compiler. But I can tell from personal
On Thu, May 17, 2001 at 09:53:59PM -0300, Alexandre Oliva wrote:
clip
I can also tell from personal experience that I haven't had trouble
with GNU tar 1.13.17 on GNU/Linux/x86, but I still haven't been able
to do backups reliably with 1.13.19 (it will generally abort part-way
through the
36 matches
Mail list logo
