Re: [Bug-tar] Tarring with --files-from/-T adds files multiple times
Tyson Tucker tyson.tuc...@gmail.com ha escrit: I haven't figured out what makes the duplicate files/directories special, but some are duplicated up to three times in the tar file. I've tested it on versions 1.17 and 1.22 on Solaris and 1.22 on Linux. To reproduce: find /usr/local/lib /usr/local/share test_file The output from `find' includes both directories and files in them. When a directory name appears in the file list, tar adds to the archive this directory and all files (including subdirectories) in it. Therefore, the resulting archive will contain N copies of each file, where N is the number of directories in the file's full name. To fix this, either tighten your find conditions (e.g. -type f), or give the --no-recursion option to tar. For more info, see http://www.gnu.org/software/tar/manual/html_node/recurse.html Regards, Sergey
Re: [Bug-tar] Extracting Archives in Windows
blackhol...@suddenlink.net ha escrit: I was wondering if somebody could help me with the syntax for extracting an archive with an absolute path name in Windows. If I change to the directory where the file is I can extract it, but if I try to call the tar command with the path I always get an error. What error do you get? Regards, Sergey
Re: [Bug-tar] Please Help
mehdi farokhi mehdi.faro...@gmail.com ha escrit: # tar -xf /dev/st0 tar: Unexpected EOF in archive This can happen if you are trying to read a multivolume archive without the `-M' option. Try tar -M -xf /dev/st0 tar: home/shares/SupplyChain/jghods/DESKTOP 111: implausibly old time stamp 1969-12-31 19:00:00 tar: Error is not recoverable: exiting now Also if is it possible expaline more about time stamp? This diagnostics means that the timestamp of the extracted file is unrealistically old. This often means that tar was unable to set the timestamp. Regards, Sergey
Re: [Bug-tar] reg tar 1.14
Gargi Thakur gargithaku...@gmail.com ha escrit: - Check version of tar. The version may not support files more than 2GB. Tar imposes no limits on the size of files it can handle. However, such limits are often imposed by file system. Additionally, some tar archive formats also limit the size of archive member. See http://www.gnu.org/software/tar/manual/html_node/Formats.html for a discussion of these. Regards, Sergey
[Bug-tar] Can't get --owner/--group to work when extracting (GNU tar 1.20)
amit0 ~ # tar --version tar (GNU tar) 1.20 I read in the manpage: QUOTE --owner USER change owner of extraced files to USER QUOTE/ Nevertheless I can't get --owner and --group to work when extracting an archive. Files in archive are owned by root: amit0 ~ # mkdir /tmp/source amit0 ~ # touch /tmp/source/file amit0 ~ # find /tmp/source/ -ls 2356093460 drwxr-xr-x 2 root root 17 Jul 30 10:57 /tmp/source/ 2356093470 -rw-r--r-- 1 root root0 Jul 30 10:57 /tmp/source/file amit0 ~ # tar czf tar.tar.gz -C /tmp source amit0 ~ # tar tvf tar.tar.gz drwxr-xr-x root/root 0 2009-07-30 10:57 source/ -rw-r--r-- root/root 0 2009-07-30 10:57 source/file amit0 ~ # rm -fr /tmp/dest/* amit0 ~ # tar xzf tar.tar.gz --owner amitds --group amitds -C /tmp/dest/ amit0 ~ # find /tmp/dest/ -ls 2695373270 drwxrwxr-x 3 root root 19 Jul 30 11:01 /tmp/dest/ 3026735850 drwxr-xr-x 2 root root 17 Jul 30 10:57 /tmp/dest/source 3026735860 -rw-r--r-- 1 root root0 Jul 30 10:57 /tmp/dest/source/file amit0 ~ # id amitds uid=1014(amitds) gid=1022(amitds) groups=1022(amitds) a/m options do seem to work when archiving: amit0 ~ # chown -R root:root /tmp/source/ amit0 ~ # tar czf tar.tar.gz -C /tmp source --owner amitds --group amitds amit0 ~ # tar tvf tar.tar.gz drwxr-xr-x amitds/amitds 0 2009-07-30 10:57 source/ -rw-r--r-- amitds/amitds 0 2009-07-30 10:57 source/file But then I don't need to apply those options upon extraction. Please advise. Is there a method of applying ownership on-extraction? Is the manpage incorrect? Amit
Re: [Bug-tar] Can't get --owner/--group to work when extracting (GNU tar 1.20)
Amit Dor-Shifer ami...@oversi.com ha escrit: amit0 ~ # tar --version tar (GNU tar) 1.20 I read in the manpage: QUOTE --owner USER change owner of extraced files to USER The manpage is wrong. The --owner option works only when creating archives. See the GNU tar manual, section 4.3.1, for a detailed description. Please, report this to the author of the manpage. Regards, Sergey
Re: [Bug-tar] bug with tar and preserving UID and GID over NFS
ajmcello ajmcell...@gmail.com ha escrit: Hi. I thought I would forward this to the tar group. Is it possible to have tar fallback to UID and GID 0 or the owner and group of the person running tar in the event that it cannot change it, particularly over NFS? Currently it is not possible to fallback to another uid/gid if tar was unable to set them. However, it is possible to override the uid/gid values stored in the archive. For example, to extract all files from `a.tar' as owned by user with uid=100 and gid=1000, run: tar -x -f a.tar --pax-option uid=100,gid=1000 Hope that helps. Regards, Sergey
[Bug-tar] tar fails to preserve hard links with --remove-files
A user of Debian noticed that tar (1.22) does not always preserve hard
links when creating an archive with the --remove-files option. Ted Ts'o
provided the following analysis:
On Sun, 13 Apr 2003 15:45:27 -0400, Theodore Ts'o ty...@mit.edu wrote:
I'm pretty sure, by the way, that the problem is that tar is keying
off of the st_nlink to decide whether or not to do hard link
processing as an optimization. When --remove-files is present, then
st_nlink of the hard-linked inode is dropping, and when st_nlink is
one, tar can't tell that it was previously a hard-linked file. The
fix would require that tar check every single file's inode number
against previously written files to see if it was a hard linked file
(instead of just checking files where st_nlink 1), in the case when
--remove-file option is in use.
I've attached two patches to fix this bug. The first implements Ted's
suggestion, (using the hard links hash table for all files when the
--remove-files option is in effect, regardless of the value of
st_nlink). The second patch adds a test case for the bug, (failing
before the first patch is added and passing afterwards).
Please let me know if you need anything else,
-Carl
PS. If you could preserve the CC list in any replies that would be
appreciated.
From f1ed85d46043c523cd5b8196c1d266f3606a2531 Mon Sep 17 00:00:00 2001
From: Carl Worth cwo...@cworth.org
Date: Wed, 29 Jul 2009 20:45:58 -0700
Subject: [PATCH 1/2] Preserve hard links with --remove-files
When the --remove-files option is in effect, it is no longer
reliable to use a file's link count to determine if we should
use the hash table for hard links. Instead, we look into the
hash table for every file when under the influence of the
--remove-files option.
---
debian/changelog |3 ++-
src/create.c |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index df3a125..747988e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,8 +3,9 @@ tar (1.22-1.2) UNRELEASED; urgency=low
* Add Carl Worth as an uploader.
* Fix to allow parallel build (-j2), closes #535319
* Don't close file stream before EOF, closes #525818
+ * Preserve hard links with --remove-files, closes #188663
- -- Carl Worth cwo...@cworth.org Wed, 29 Jul 2009 16:18:18 -0700
+ -- Carl Worth cwo...@cworth.org Wed, 29 Jul 2009 21:28:45 -0700
tar (1.22-1.1) unstable; urgency=low
diff --git a/src/create.c b/src/create.c
index fde7ed1..559aaa0 100644
--- a/src/create.c
+++ b/src/create.c
@@ -1377,7 +1377,7 @@ static Hash_table *link_table;
static bool
dump_hard_link (struct tar_stat_info *st)
{
- if (link_table st-stat.st_nlink 1)
+ if (link_table (st-stat.st_nlink 1 || remove_files_option))
{
struct link lp;
struct link *duplicate;
@@ -1424,7 +1424,7 @@ file_count_links (struct tar_stat_info *st)
{
if (hard_dereference_option)
return;
- if (st-stat.st_nlink 1)
+ if (st-stat.st_nlink 1 || remove_files_option)
{
struct link *duplicate;
struct link *lp = xmalloc (offsetof (struct link, name)
--
1.6.3.3
From a75570c728ed2c3f65fb075491a07a9b4ade407f Mon Sep 17 00:00:00 2001
From: Carl Worth cwo...@cworth.org
Date: Wed, 29 Jul 2009 21:26:23 -0700
Subject: [PATCH 2/2] Add hardlinks test (to ensure they are preserved with --remove-files)
The new hardlinks.at test case verifies the fix in the previous
commit, (without that change the test fails, and with the change
the test passes).
---
tests/hardlinks.at | 50 ++
tests/testsuite.at |2 ++
2 files changed, 52 insertions(+), 0 deletions(-)
create mode 100644 tests/hardlinks.at
diff --git a/tests/hardlinks.at b/tests/hardlinks.at
new file mode 100644
index 000..9e01ec3
--- /dev/null
+++ b/tests/hardlinks.at
@@ -0,0 +1,50 @@
+# Process this file with autom4te to create testsuite. -*- Autotest -*-
+
+# Test suite for GNU tar.
+# Copyright (C) 2009 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+# Problem: hard links not preserved with --remove-files
+# Reported by: Theodore Y. Ts'o ty...@mit.edu
+# References: e194eae-0001le...@think.thunk.org
+# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188663
+
+AT_SETUP([preserve hard links with
Re: [Bug-tar] hard links and --transform
Hi there.. i just stumbled over the same problem when transforming hardlinks.. the following short patch fixes the problem for me.. (without applying the previous patch) since i haven't found a final fix here is my solution just for your information 8).. grettings from berlin/germany.. marius tolzmann.. === RCS file: src/create.c,v retrieving revision 1.1 diff -au -r1.1 src/create.c --- src/create.c2009/07/30 16:16:51 1.1 +++ src/create.c2009/07/30 16:26:46 @@ -1397,6 +1397,7 @@ block_ordinal = current_block_ordinal (); assign_string (st-link_name, link_name); + transform_name(st-link_name, XFORM_LINK); if (NAME_FIELD_SIZE - (archive_format == OLDGNU_FORMAT) strlen (link_name)) write_long_link (st); Original Message: - Sergey Poznyakoff wrote: Jose Miguel Goncalves addr...@hidden ha escrit: I'm facing the same problem reported back in March, 17 by Wouter Verhelst, regarding storing hard links in tar using --transform. I'm using tar 1.22. I must have overlooked the original report. Please, try the attached patch. Let me know if it works for you. It works! $ /usr/local/bin/tar cPvf test.tar --transform=s,^basedir,,h --show-stored-names basedir / /test /test_link $ /usr/local/bin/tar tPvf test.tar drwxr-xr-x jmpg/jmpg 0 2009-06-25 16:49 / -rw-r--r-- jmpg/jmpg 6 2009-06-25 13:13 /test hrw-r--r-- jmpg/jmpg 0 2009-06-25 13:13 /test_link link to /test But, when I give 'H' in the transformation scope flag it still does the transformation: $ /usr/local/bin/tar cvPf test.tar --transform=s,^basedir,,H --show-stored-names basedir / /test /test_link $ /usr/local/bin/tar tPvf test.tar drwxr-xr-x jmpg/jmpg 0 2009-06-25 16:49 / -rw-r--r-- jmpg/jmpg 6 2009-06-25 13:13 /test hrw-r--r-- jmpg/jmpg 0 2009-06-25 13:13 /test_link link to /test Only if I supply 'R' tar does not make the transformation: $ /usr/local/bin/tar cPvf test.tar --transform=s,^basedir,,R --show-stored-names basedir basedir/ basedir/test basedir/test_link $ /usr/local/bin/tar tPvf test.tar drwxr-xr-x jmpg/jmpg 0 2009-06-25 16:49 basedir/ -rw-r--r-- jmpg/jmpg 6 2009-06-25 13:13 basedir/test hrw-r--r-- jmpg/jmpg 0 2009-06-25 13:13 basedir/test_link link to basedir/test so, it seems that some bug(s) still persist. Best regards, J
Re: [Bug-tar] hard links and --transform
Hi Marius, i just stumbled over the same problem when transforming hardlinks.. the following short patch fixes the problem for me.. (without applying the previous patch) Thanks for the suggestion. since i haven't found a final fix here is my solution just for your information 8).. The final fix is already in the Git repository. You may also find it here: http://lists.gnu.org/archive/html/bug-tar/2009-07/msg00011.html Regards, Sergey
Re: [Bug-tar] tar fails to preserve hard links with --remove-files
Carl Worth cwo...@cworth.org ha escrit:
A user of Debian noticed that tar (1.22) does not always preserve hard
links when creating an archive with the --remove-files option.
Thanks for reporting.
On Sun, 13 Apr 2003 15:45:27 -0400, Theodore Ts'o ty...@mit.edu wrote:
I'm pretty sure, by the way, that the problem is that tar is keying
off of the st_nlink to decide whether or not to do hard link
processing as an optimization.
Yes, that's right.
I've attached two patches to fix this bug. The first implements Ted's
suggestion, (using the hard links hash table for all files when the
--remove-files option is in effect, regardless of the value of
st_nlink).
This one is mostly OK, except that I don't see any reason to test the
remove_files_option value in file_count_links. This will unnecessarily
inflate the link_table and slow down archive creation.
I have installed the attached patch.
Regards,
Sergey
From 5944f452b0e615a172a9f058877671ff6272abb8 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff g...@gnu.org.ua
Date: Thu, 30 Jul 2009 23:48:04 +0300
Subject: [PATCH] Fix hard links recognition with -c --remove-files
* src/create.c (dump_hard_link): Always look up in the link table
if remove_files_option is set. Patch suggested by Theodore Ts'o
ty...@mit.edu.
(check_links): Remove extra newline from the warning message.
* tests/link02.at, tests/link03.at: New testcases.
* tests/Makefile.am (TESTSUITE_AT): Add link02.at and link03.at
* tests/testsuite.at: Include link02.at and link03.at
---
src/create.c |4 +-
tests/Makefile.am |2 +
tests/link01.at|4 +-
tests/link02.at| 52
tests/link03.at| 56
tests/testsuite.at |2 +
6 files changed, 116 insertions(+), 4 deletions(-)
create mode 100644 tests/link02.at
create mode 100644 tests/link03.at
diff --git a/src/create.c b/src/create.c
index 245b6c3..1031cc2 100644
--- a/src/create.c
+++ b/src/create.c
@@ -1377,7 +1377,7 @@ static Hash_table *link_table;
static bool
dump_hard_link (struct tar_stat_info *st)
{
- if (link_table st-stat.st_nlink 1)
+ if (link_table (st-stat.st_nlink 1 || remove_files_option))
{
struct link lp;
struct link *duplicate;
@@ -1468,7 +1468,7 @@ check_links (void)
{
if (lp-nlink)
{
- WARN ((0, 0, _(Missing links to %s.\n), quote (lp-name)));
+ WARN ((0, 0, _(Missing links to %s.), quote (lp-name)));
}
}
}
diff --git a/tests/Makefile.am b/tests/Makefile.am
index da6cf0d..2001834 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -77,6 +77,8 @@ TESTSUITE_AT = \
indexfile.at\
ignfail.at\
link01.at\
+ link02.at\
+ link03.at\
listed01.at\
listed02.at\
long01.at\
diff --git a/tests/link01.at b/tests/link01.at
index 2bec558..5faf42e 100644
--- a/tests/link01.at
+++ b/tests/link01.at
@@ -1,7 +1,7 @@
# Process this file with autom4te to create testsuite. -*- Autotest -*-
# Test suite for GNU tar.
-# Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2007, 2009 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -31,7 +31,7 @@
# http://lists.gnu.org/archive/html/bug-tar/2004-07/msg9.html
AT_SETUP([link count gt 2])
-AT_KEYWORDS([link01])
+AT_KEYWORDS([hardlinks link01])
AT_TAR_CHECK([
mkdir directory
diff --git a/tests/link02.at b/tests/link02.at
new file mode 100644
index 000..756d48f
--- /dev/null
+++ b/tests/link02.at
@@ -0,0 +1,52 @@
+# Process this file with autom4te to create testsuite. -*- Autotest -*-
+
+# Test suite for GNU tar.
+# Copyright (C) 2009 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+# Tar 1.22 failed to recognize last hard link when creating an archive with
+# the --remove-files option.
+#
+# Reported by: Theodore Y. Ts'o ty...@mit.edu,
+# Carl Worth cwo...@cworth.org
+# References:
+# e194eae-0001le...@think.thunk.org
+# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188663
+# 1248955024.1545.1.ca...@yoom.home.cworth.org
+# http://lists.gnu.org/archive/html/bug-tar/2009-07/msg00015.html
+
Re: [Bug-tar] tar fails to preserve hard links with --remove-files
On Thu, 2009-07-30 at 23:52 +0300, Sergey Poznyakoff wrote: Thanks for reporting. Thank you, Sergey. And thanks for the quick reply. This one is mostly OK, except that I don't see any reason to test the remove_files_option value in file_count_links. This will unnecessarily inflate the link_table and slow down archive creation. I had expected to only have to add it in one location, and I thought I even tested it that way first. (But maybe I made the mistake and added it to the wrong one.) Anyway, I'm glad to see a version of this land upstream. I have installed the attached patch. Excellent. I'll incorporate that into Debian's package for now, and look forward to seeing this change appear in a future release. -Carl signature.asc Description: This is a digitally signed message part
