root@server # tar fcz bkup.tar.gz /home/foo/
tar: Removing leading `/' from member names
How can I solve this problem and keep the /
on file names ?
If you want to get rid of "Removing leading `/' from member names" being printed to STDERR, but still want to leave off those leading slashes as tar wisely does by default, I saw an excellent solution here by commenter timsoft.
The solution involves using -C option to change directory to the root (/), then specifying the file tree to archive without a leading slash, because now you only need a relative path. This does the same thing as a normal tar create command, but no stripping is needed:
tar fcz bkup.tar.gz -C / home/foo/
tar c -C / home/foo/*
), because the shell doesn't know about the changed root. But still a good answer for other cases.
-C /
doesn't work for me, period. It doesn't prevent the stderr for me.
Aug 10, 2015 at 7:45
Use the --absolute-names
or -P
option to disable this feature.
tar fczP bkup.tar.gz /home/foo
tar fcz bkup.tar.gz --absolute-names /home/foo
-C /
option as described in @Marcus' answer will git rid of the STDERR message if that is your primary goal.
Dec 28, 2013 at 22:29
tar
also removes the leading slash by default when extracting. So even if you use this option when creating the archive, it won't be a problem unless the user also uses it when extracting.
That's actually a feature, not a problem. Archives with absolute locations are a security risk. Attackers could use such archives to trick users into installing files in critical system locations.
Yes, you could use -P
. But what's wrong with allowing tar to remove the forward slash, and simply requiring the user of the archive to explicitly do the extraction in the root directory? Then they're consciously impacting critical system locations, and can't do it by accident.
tar
. This particular message was causing tar
to exit with a status of 1
, which was causing me to receive false email alerts on successful backups, simply because tar
was writing this message to STDERR. I fixed this issue by using my own tweaked version of @Marcus's solution: cd /path/to/network/share && tar -cJf scripts.backup.tar.xz -C / home/user/scripts 2>/dev/null || [send an email alert]
Dec 14, 2015 at 19:14
-P
- for example, if you're providing some kind of filesystem snapshotting feature in FUSE. Some of the time you may want to untar a snapshot in a specific directory rather than the cwd
from the perspective of the user.
One month late, but I found the most appropriate solution for my case (in a shell script) is to go to the parent directory and execute the command there.
cd /var/www/
tar -czf mysite.gz mysite
Instead of:
tar -czf /var/www/mysite.gz /var/www/mysite
This is how I did it by using brute force method: 2>&1 | grep -v "Removing leading"
.
For example:
tar -cf "$BKUPDIR/${BKUPFILE}.tar" --overwrite --exclude '.*' --one-file-system "$SRCDIR" 2>&1 | grep -v "Removing leading"
Try to use -C
for path only which would prevent compressing with complete paths:
root@server # tar fcz bkup.tar.gz -C /home/ foo/
I solved this problem with:
cd /home/foo && tar czf ~/backup.tar.gz .
that way you aren't trying to put absolute paths into the tar archive in the first place. If you want untar it at the root of the file system you just
cd / && tar xzf backupt.tar.gz
after transferring it.
The path of the archive when specified causes this informational message, you can do the following to resolve it:
tar -zvcf /tmp/mike.tar.gz -P /tmp/mike
or
tar -zvcf mike.tar.gz -P /tmp/mike
or
tar -zvcf mike.tar.gz /tmp/mike
Note: it is not an error, just informational.
its not a feature, its a bug. removing absolute paths creates an unextractable archive if path data gets fooey somehow. tar spits out the error and refuses to extract anything. better to use tardy to filter the path first.
/
removed during creation? To what TAR versions does your comment apply? With GNU tar, I certainly haven't experienced any problems during extraction.
-C /
when extracting it.tar: Removing leading `/' from hard link targets