Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
what do you want suggestions about? tar archives don't contain absolute paths, only relative ones. this is correct behaviour, as the alternative is really nasty and illogical. this is the same way that other compression programs like winzip work. when you untar somethign you provide an destination directory, which implicity is '/' in your case... but it should be explicit for logical operation.
The name of the archive file MUST follow the f. Therefore that is the wrong place for the P parameter. And I believe that the c must be the first parameter. Not positive about that.
Code:
tar czPf archive.tgz /home
Also, the - isn't doing any harm. Who cares if he is using BSD or GNU parameter style?
@guarriman: acid_kewpie makes a good point. The file paths in a tar archive are stored as relative paths for a good reason. It gives you more flexibility about where to restore files. You may want to restore files into a temporary location. The relative path makes this possible. If the file paths in the tar archive were absolute then you would have to chroot into a temporary directory in order to restore the files anywhere but their original location.
Last edited by stress_junkie; 07-04-2008 at 03:15 PM.
...and there are system harmful or grave security implications when extracting with absolute pathnames or relative symbolic links that contain "..". Use cautiously.
this way you avoid the security hazards of the -P option and avoid the warning message about stripping /
note the "-C /" before the dir to be backed up and the removed leading /
this tells tar to change to the root ( / ) directory first, and then of course your path minus the leading /
is still the same place, even if it is relative.
It means you can restore your files easily elsewhere, as per stress_junkie's comment.
The name of the archive file MUST follow the f. Therefore that is the wrong place for the P parameter. And I believe that the c must be the first parameter. Not positive about that.
This is not quite correct. When you use the "new" syntax (i.e. with a leading -) then the filename must immediately follow the f as is usual for unix commands, but with tar's "traditional" syntax, the first "word" is a list of command/option letters and any following arguments must be in the same order as the letters (for options that take arguments, of course). This means that, e.g.
Code:
tar fcz filename ...
is correct, even though it is irrational and prone to error.
It is preferable to use the "new" syntax, using a - for all options.
Code:
tar -zcf filename...
The c does not have to be first, it can be anywhere (with either syntax), though there may be some versions of tar the require the command to be first?
Last edited by smoked kipper; 08-02-2008 at 12:47 PM.
The c does not have to be first, it can be anywhere (with either syntax), though there may be some versions of tar the require the command to be first?
Indeed, this used to be the case, and I'm no longer sure what the rules are for various tars. It was always a stupid requirement, and the command options without the dash was one of those dumb exceptions to an almost universally consistent Unix command line syntax.
Also, the - isn't doing any harm. Who cares if he is using BSD or GNU parameter style?
Just to let you guys know that the '-' actually seems to do harm.
Code:
statistic@SewagePlant:~$ tar -zcfP test.tar /home/statistic/webmail_auth
tar: test.tar: Cannot stat: No such file or directory
tar: Removing leading `/' from member names
tar: Error exit delayed from previous error
Then I try
Code:
statistic@SewagePlant:~$ tar zcfP test.tar /home/statistic/webmail_auth
and now it seems to work.
Before the obvious question rolls in, I'm running Ubuntu 8.04. So just to let you guys know, that sometimes, for some reason, the '-' does matter.
The c does not have to be first, it can be anywhere (with either syntax), though there may be some versions of tar the require the command to be first?
I'm running Arch Linux, which uses the GNU version of tar; the function parameter ('c' in this case) does have to come first with this distro. I always (a) use the '-' (it's self-documenting), (b) put the function code (c,x,t,etc) first, and (c) put the "f" option LAST. Seems to me a good habit to pick up.
==> statistic:
It's not the '-' that's giving you errors - it's the option order! "tar czPf ..." and "tar -czPf ..." both work here...
Last edited by grndrush; 01-04-2009 at 12:26 PM.
Reason: typo
Ok neat, so it seems that the order of the parameters is important only WITH the dash on my system (Ubuntu), but order is not important without the dash.
That seems odd, I wonder if it is because when you include the dash, it shifts to GNU mode and enforces the correct ordering of parameters, whereas without the dash it does not enforce any other GNU standards. It's not really important, but please correct me if I'm wrong, I would like to understand.
*I* do not know (I'd like to understand tar better, also!), but your line of thinking is in line with mine, completely. Makes sense. I did a few googles on the topic yesterday, and one of the links had a comment to the effect that the famous optional "-" in tar was an abberation (not their term; I can't remember now the term they used) and completely inconsistent with the way the REST of Linux works. I agree completely and have felt that way since my first Linux install.
Of course, tar is a REALLY old, and critical, tool, and backwards compatibility is highly important - changing the command line in real-time is easy, but who KNOWS how many thousands of Linux scripts there are, world-wide, which have a tar command in them. Nothing's perfect - and Linux is MUCH more "consistent", overall, than ANYTHING ever released by M$.
Last edited by grndrush; 01-05-2009 at 09:59 PM.
Reason: typo
I believe that tar may have been written before the "dash" convention was introduced. The "-f" option needs an argument, so the line containing the "fP" options was wrong. That command will create an archive named "P" and add the file test.tar and the directory /home/statistic/webmail_auth to the archive. Obviously not what you wanted to do.
If you have two options that take arguments, then you need to use the dash. For example, it is common to start with the -C option to change the base directory where tar should extract the files.
The -f option is required. Since you can't group all of the options together, dashes are needed.
As far as I am concerned, alway use the dash.
Actually, I thought the exact same thing, and tried it on my system. To my astonishment, it DIDN'T do as you (and I) expected. Again, I run Arch - YMMV w/other distros.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.