Extracting from a tarball

S

SingerMan

Hello all,

I created a large tarball (tar.gz) of Linux data and sent it to a FreeBSD machine. Although I can list the files in the tarball while in the FreeBSD machine, I cannot extract from the tarball. I keep getting the error message:
Code: 
Pathname in pax header can't be converted to current locale.
(I'm using all the same commands in FreeBSD that work to extract from a tarball while in Linux.)

Does anyone know what might be wrong?
 
I'm sorry, I meant to add that it works if I want to extract the entire tarball -- it's a large one 180GB. But when I try to extract one directory or one file from it -- just to verify that it's a good tar backup -- I get the above mentioned message. (Again, I'm using the same commands that work while I'm in Linux.)

Does it matter in FreeBSD that a directory name has dashes or periods in it? I've tried putting quotes around the name, but that doesn't help.
 
SingerMan said:
Does anyone know what might be wrong?
Click to expand...
For starters Linux uses GNU tar while BSDs have their own implementation of tar.
Code: 
[root@backup1] ~# uname -a
FreeBSD backup1.mylab.org 10.0-RELEASE-p15 FreeBSD 10.0-RELEASE-p15 #3 bde22ec(releng/10.0): Fri Aug  1 03:19:22 EDT 2014
[root@backup1] ~# tar --version
bsdtar 3.1.2 - libarchive 3.1.2

Code: 
 oko@loom$ uname -a
Linux loom..cmu.edu 2.6.32-504.el6.x86_64 #1 SMP Fri Oct 17 13:34:40 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
oko@loom$ tar --version
tar (GNU tar) 1.23
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
 
From Oko:
For starters Linux uses GNU tar while BSDs have their own implementation of tar.
Click to expand...


I am utilizing FreeBSD 9.1 with bsdtar 2.8.5 and OpenSuSE 13.1 with GNU tar 1.26.

However, according to Cyberciti and other sites the CLI tar commands are the same.
 
From rmoe:
Are you sure that your locale settings aren't different?
Click to expand...

The locales are different: Linux displays “en_US.UTF-8” and FreeBSD “C”

I've tried to change the locale for a single user – as a non-root user with these commands:


Code: 
 me:\

:charset=UTF-8:\

:lang=en_US.UTF-8:\

:setenv=LC_COLLATE=C:


I get the message: “command not found” I suppose that means that I need to do that as root, but I don't yet know how to just change it for one user. Still looking...
 
SingerMan said:
From rmoe:

The locales are different: Linux displays “en_US.UTF-8” and FreeBSD “C”

I've tried to change the locale for a single user – as a non-root user with these commands:


Code: 
 me:\

:charset=UTF-8:\

:lang=en_US.UTF-8:\

:setenv=LC_COLLATE=C:


I get the message: “command not found” I suppose that means that I need to do that as root, but I don't yet know how to just change it for one user. Still looking...
Click to expand...
You don't execute these commands, you put them in ~/.login_conf then log out and log in again. I think that you also have to run cap_mkdb .login_conf.
 
OK, here's how I usually do it:

Edit /etc/login.conf (as root)

If you want those settings for all users, have the following in the default: section:
Code: 
        :charset=UTF-8:\
        :lang=en_US.UTF-8:
at the end of that section.

If it should be specific for one user only or one group only then create a section for that, insert the same two lines but aditionlly add :tc=default: as last line. If you don't know how to create such an entry, just copy or edit one of the examples in the file.
Either way, be sure that all lines before your new lines end with a backslash and that the last line of the section has no backslash at the end.

Finally, don't forget to cap_mkdb /etc/login.conf (also as root).

In case you don't have the possibility to become root on that box, you may set the propoer environment variables for your shell.
 
SingerMan said:
From Oko:


I am utilizing FreeBSD 9.1 with bsdtar 2.8.5 and OpenSuSE 13.1 with GNU tar 1.26.

However, according to Cyberciti and other sites the CLI tar commands are the same.
Click to expand...
I have never heard of Cyberciti. Am I supposed to trust them better then to my own ability to read and process man pages? If you check out man pages of OpenBSD tar from which I am typing you this message and GNU tar you will find out that not all commands are the same and more importantly that programs don't behave the same way. Similarly yes but not the same! However functionality of gtar (GNU tar) from BSD ports and the tar you are accustomed to on your Linux machine should be 100% the same.
 
Last edited by a moderator:
In short;
# cd /usr/ports/archivers/gtar && make install clean
followed by:
# man gtar.
You should then be golden. :)
Simple as that. :)

--Chris
 
Greetings, again, SingerMan.
Well, as I have had no use for it. I had to install a copy of archivers/gtar. Just so I could have a good look at all the documentation (man(1) / info(1) pages), and give you a more informed reply. :)
Not having acces to the tar ball, itself. But given the output provided in your OP, and your explanations. It appears that you are working from a dump(8) style archive (pax(1)). In that case, you will be mostly interested in the -g, and -G options, and the requirements (requisite file(s)) that (should?) normally accompany that style of archive/backup. If I understand it all correctly. The (your) issue stems from the fact that gtar(1) is looking for an INDEX (table of contents), and you aren't providing it. So it is unable to extract targeted pieces (files, or folders) from the archive. It's only option is to dump, or list the entire structure.
Excerpt (from the info(1) pages, follows:
-g, --listed-incremental=FILE
Handle new GNU-format incremental backups. FILE is the
name of a snapshot file, where tar stores additional
information which is used to decide which files changed
since the previous incremental dump and, consequently,
must be dumped again. If FILE does not exist when creat-
ing an archive, it will be created and all files will be
added to the resulting archive (the level 0 dump). To
create incremental archives of non-zero level N, create a
copy of the snapshot file created during the level N-1,
and use it as FILE.

When listing or extracting, the actual contents of FILE
is not inspected, it is needed only due to syntactical
requirements. It is therefore common practice to use
/dev/null in its place.

-G, --incremental
Handle old GNU-format incremental backups.
Click to expand...

Please examine the OPTIONS section of the info(1) pages for additional information related to these options.

HTH

--Chris
 
Another option you might want to consider, which might ultimately turn out to be a great deal easier, and quicker. Would be to browse the ports/archivers section, and pick a converter, and simply convert the archive to something a bit more universal. Given the current state of it now. The Locale business seems to be tied to the hard drive it was made from. I'm not keen enough on all the EA's for all the different drive types available today, and I'm perfectly happy on UFS(2). :)

--Chris

One last thing, before I head to bed; You might try making a copy of the tar ball, and ask BSDtar to add a file to it. This may cause BSDtar to rewrite the header, and eliminate the nonsense Gtar is complaining about. Making it a BSDtar ball.

Just a thought. :)

Chris out...
 
Hi Chris, much thanks for your reply and your efforts.

This FreeBSD machine is a backup server. It has a minimal install, just Samba, no X-windows etc. It's all CLI. I use Acronis True Image to send backups to it from my two Windows boxes – one HTPC and my DAC; those are fine.

My 'daily driver' is OpenSuSE; it has a second data drive with lots of data on it (160GB), That's the backup I'm having issues checking. As I said above, listing the tarball's contents (while in FreeBSD) seems to work fine; it's only when I want to extract a single file or directory to check it that I have trouble.

Originally, I sent the tarred directory from the SuSE machine to the FreeBSD machine in one-step using ssh:

Code: 
 tar zcvf – directory-name | ssh me@Unix-Storage "cat > /data1/Linux-Backups/directory-name-10-30-2014.tar.gz"

Since your last post. I decided to simply send the uncompressed directory via scp and then tar it in FreeBSD. (Then delete the big uncompressed directory I sent.)

Laborious, but it worked. I have since extracted several directories and files arbitrarily to check the tarball; it's fine.

I have two things left to solve:

  1. It seems to me that what I'd like to do, if I could get the right code, is to run the above code in reverse – i.e. run it from the FreeBSD machine. (That would prevent any tar issues.) I can't quite make that work yet.
  2. Figure out why I still can't change the locale for a single user on the FreeBSD machine.
(If I can't figure out how to do (1) in one-step from the FreeBSD machine I'll try your converter suggestion.)

Thanks for any help you can offer.
 
Greetings, SingerMan.
Glad to see you at least got something usable. :)

Just for the record; the difference(s) between the two versions of tar(1), you're working with is that the FreeBSD version is POSIX. Where the GNU tar has additional "features" that do not comply to the POSIX standards. Now you know why POSIX (and, as a result; FreeBSD) are the best choice(s) ;)

That said. I have a copy of the "pay for" version of SUSE LINUX Server. But haven't used it in quite some time. As I can remember, there were some "extensions" for Locale that are used liberally throughout the applications on it. Which again, aren't POSIX. In any event. If I'm not mistaken. You might be able to get away with using the GNU tar if you only use switches and "options" that are available on POSIX versions of tar (BSDtar).

As to the locale(1). If you can get root on your system, you should be able to adjust the values either temporarily, within your shell (.cshrc,...), or through login(1), login.conf(5), locale(1), setlocale(1). Doing so through login.conf(5) also requires updating the database read by the system.

Have a look in /usr/share/examples, as well as /usr/local/share/etc for some of the defaults, and adjust for your own needs.

--Chris
 
You must log in or register to reply here.
Back
Top