/bin/tar: Removing leading `/' from member names
Hi.
I wrote a script: /bin/tar -zcf /home/user/backup_www.tar.gz /var/www/html It works, but I get this warning message: /bin/tar: Removing leading `/' from member names I removed the first '/' from '/home/user...' but it does not work. Any suggestion? Thank you very much. |
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.
|
Quote:
The "P" option should help you there. See man tar |
Quote:
/bin/tar zcfP ... |
Quote:
Code:
tar czPf archive.tgz /home @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. |
...and there are system harmful or grave security implications when extracting with absolute pathnames or relative symbolic links that contain "..". Use cautiously.
|
solution
A solution to your backup without changing the nature of the tar file you create, and avoiding the stripping message would be
/bin/tar -czf /home/user/backup_www.tar.gz -C / var/www/html 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. |
Quote:
Code:
tar fcz filename ... It is preferable to use the "new" syntax, using a - for all options. Code:
tar -zcf filename... |
Quote:
|
Hey, sorry to revive a dead thread.
Quote:
Code:
statistic@SewagePlant:~$ tar -zcfP test.tar /home/statistic/webmail_auth Code:
statistic@SewagePlant:~$ tar zcfP test.tar /home/statistic/webmail_auth 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. |
Quote:
==> statistic: It's not the '-' that's giving you errors - it's the option order! "tar czPf ..." and "tar -czPf ..." both work here... |
==> grndrush:
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. :) |
Statistic -
*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$. :) |
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. |
jschiwal -
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. Ah, technology! ;) |
Thanks for for all the information guys :)
|
Just wanted to say thanks for a great thread. I personally skipped the absolute paths (P) option and just navigated to the directory containing the folder I wanted to tar, e.g.
Note: This was in OSX 10.4 tar -cjf /Volumes/10.10.0.123/TestDir/TESTTHIS.tbz TESTTHIS instead of tar -cjf /Volumes/10.10.0.123/TestDir/TESTTHIS.tbz /foo/TESTTHIS Wanted to post a side note for OSX users, you may want to consider running Mac OS X v10.4 and later: How to prevent .DS_Store file creation over network connections defaults write com.apple.desktopservices DSDontWriteNetworkStores true or OS X, tar and Resource Forks export COPY_EXTENDED_ATTRIBUTES_DISABLE=true if you're in a multi-OS environment. |
All times are GMT -5. The time now is 09:13 PM. |