FYI: This is the information that Chapman Flack has submitted to bug-tar.
J Chapman Flack wrote: > I've submitted a report that's awaiting moderator approval. I can send > you the link to it on bug-tar as soon as it goes through. http://lists.gnu.org/archive/html/bug-tar/2010-06/msg00000.html There was a similar report (different circumstances, but very likely the same bug) reported last week: http://lists.gnu.org/archive/html/bug-tar/2010-05/msg00026.html -Chap > -----Original Message----- > From: owner-amanda-us...@amanda.org [mailto:owner-amanda- > us...@amanda.org] On Behalf Of McGraw, Robert P > Sent: Wednesday, June 02, 2010 11:23 AM > To: 'Nathan Stratton Treadway'; 'amanda-users@amanda.org' > Cc: 'jfl...@math.purdue.edu' > Subject: RE: runtar error that I do not understand > > > I am not sure if this got sent to the group so I an fordwarding. > > This explains what is going on in the gtar code to cause gtar to seg > fault. All the accolades should go to my SA partner Chapman Flack. He > is in the process of sending this to bug-tar as suggested. > > Robert > > ---- > > "Apparently under only some circumstances, gtar tries to use the old > algorithm for finding the cwd. That fails beneath .zfs which is a sort > of magical name that isn't there unless you're looking for it exactly. > > But it must just be a special combination of options that makes gtar > try to do that, because in simple invocations it doesn't: > > hertz /homes % ls .z* # nobody here but us chickens... > ls: No match. > hertz /homes % cd .zfs # oh, you mean ME? > hertz .zfs % cd snapshot/TODAY/jflack > % gtar --create --file /dev/null bar # works fine > > Aha, it's the --listed-incremental option. This makes gtar want to > create the snar file with names and metadata of files it sees: > > % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar > Segmentation fault > > The funny thing is, if I cd to ~ where it works... > > % cd ~ > % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar % > > ...and then look in /tmp/snar, it only contains relative paths... > ...so it STILL doesn't explain why gtar even wants to get the cwd in > that case, but it's clear from the truss that's what it's doing. > > One workaround might be to do a loopback mount of the desired snapshot > onto some other path that's not beneath .zfs, and do the backup from > there. > > -Chap" > > > -----Original Message----- > > From: owner-amanda-us...@amanda.org [mailto:owner-amanda- > > us...@amanda.org] On Behalf Of Nathan Stratton Treadway > > Sent: Tuesday, May 04, 2010 2:45 PM > > To: amanda-users@amanda.org > > Subject: Re: runtar error that I do not understand > > > > > > On Tue, May 04, 2010 at 13:03:09 -0500, Dustin J. Mitchell wrote: > > > On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P > > <rmcg...@purdue.edu> wrote: > > > > I setup a lookback for the snapshot and now gtar seem to be > > working. > > > > > > It sounds like you have a fairly good understanding of this problem > > > now. Could you write up either a troubleshooting or How-To article > > on > > > the wiki? > > > > Also, you might want to send a bug report about this to the > > bug-...@gnu.org list -- even if the underlying problem is that .zfs > > doesn't behave normally, I suspect they'd be interested in knowing > > about > > the issue so that they can at least avoid having an abort-with- > segfault > > in that situation... > > > > http://www.gnu.org/software/tar/#maillists > > > > > > Nathan > > > > --------------------------------------------------------------------- > -- > > ----- > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic > region > > Ray Ontko & Co. - Software consulting services - > > http://www.ontko.com/ > > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: > > 1023D/ECFB6239 > > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 > >
